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Program and System Information Protocol 
for Terrestrial Broadcast and Cable - Revision A 

ATSC Standard 

1. SCOPE 

1.1 Purpose 

This document defines a Standard for System Information (SI) and Program Guide (PG) 
data compatible with digital multiplex bit streams constructed in accordance with ISO/lEC 
1 381 8- i (MPEG-2 Systems), The document defines the standard protocol for transmission of the 
relevant data tables contained within packets carried in the Transport Stream multiplex. The 
protocol defined herein will be referred to aa Program and System Information Protocol 
(PSIP). 

This standard was prepared by the Advanced Television Systems Comminee (ATSC) 
Technology Group on Distribution (T3). The document was approved by the members of the 
ATSC on 23 December 1997. Revision A to PSIP (31 May 2000) is the result of incorporating 
PSIP Corrigendum A/66 and PSIP Amendment A/67 after their approval by the full ATSC. 
Please note that there is an Amendment No. ! to this revision located at the end of this document. 
This amendment, featuring the Directed Channel Change capability, was approved by the ATSC 
membership on 31 May 2000. 

For an informative description of the purpose, concepts, and tables defined in this 
protocol, first time readers are encouraged to start with Annex D. 

1.2 Application 

This document describes tables that shall be applicable to terrestrial (over-the-air) and 
cable signals. Some PSIP tables apply to terrestrial broadcast, some apply to cable, and others 
apply to both. 

1.2.1 Terrestrial Broadcast 

The following PSIP data shall be included in all ATSC-compiiant Transport Streams to 
be transmitted via terrestrial broadcast: 

• The Terrestrial Virtual Channel Table (TVCT) defining, at a minimum, MPEG-2 
programs embedded in the Transport Stream in which the TVCT is carried. 



NOTE: The user's attention is caiied to the possibility that compliance with this standard may require use of an 
invention covered by patent rights. By publication of this standard, no position is taken with respect to the validity of 
this claim, or of any patent rights to connection therewith. The patent holder has, however, filed a statement of 
willingness to grant a license under these rights on reasonable and nondiscriminatory terms and conditions to 
applicants desiring to obtain such a license. Details may be obtained from the publisher. This document will undergo 
periodic review and may be subject to change by ballot of the ATSC membership. 
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® The Master Guide Table (MGT) defining the type, packet identifiers, and versions for 
ali the other PSIP tables in this Transport Stream, except for the System Time Table 
(STT). 

• The Rating Region Table (RRT) defining the TV parental guideline system referenced 
by any content advisory descriptor carried within the Transport Stream. 

• The System Time Table (STT), defining the current date and time of day. 
» A service_location_descriptor for each digital yirtual channel in the VCT. 

• The first four Event Information Tables (EIT-0, E3T-1, EIT-2 and EIT-3) describing 
12 hours of events (TV programs), each with a coverage of 3 hours, and including all 
of the virtual channels listed in the TVCT. 

1.2.2 Cable 

The following PSIP data shall be included in all ATSC-compliant Transport Streams to 
be transmitted via cable: 

• The Cable Virtual Channel Table (CVCT) defining, at a minimum, the virtual channel 
structure for the collection of MPEG-2 programs embedded in the Transport Stream 
in which the CVCT is carried. 

« The Master Guide Table (MGT) defining the type, packet identifiers, and versions for 
all of the other PSIP tables included in this Transport Stream except for the System 
Time Table (STT). 

• The Rating Region Table (RRT) defining the TV parental guideline system referenced 
by any content advisory descriptor carried within the Transport Stream. 

• The System Time Table (SIT), defining the current date and time of day. 

1.3 Organization 

The sections of this document are organized as follows: 

• Section 1 — Provides this general introduction. 

• Section 2 — Lists references and applicable documents. 

• Section 3 — Provides a definition of terms and a list of acronyms and abbreviations 
used In this document. 

• Section 4 — Describes the data structure of the PSIP tables. 
- Section 5 — Describes the overall table hierarchy. 

• Section 6 — Describes formats for all. of the PSIP tables. 

• Section 7 — Describes PSIP STD model. 

• Annex A — Describes the daylight savings time control. 

• Annex B — Describes the assignment of major_channel_number values for terrestrial 
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broadcast in the U.S. 

• Annex C — Describes the standard Huffman tables for text compression. 

■ Annex D — Provides an overview of PSIP for terrestrial broadcast with application 
examples. 

• Annex E — Describes the typical sizes of PSIP tables. 

• Annex F — Provides an overview of Huffman-based text compression. 

• Annex G — Provides an overview of the use of PSIP for cable. 

2. REFERENCES 

The following documents are applicable to this Standard: 

1 . ATSC Standard A/52 (1995), Digital Audio Compression (AC-3) (normative). 

2. ATSC Standard A/53 (1995), ATSC Digital Television Standard (normative). 

3. ATSC Standard A/55 (1996), Program Guide for Digital Television (informative). 

4. ATSC Standard A/56 (1996), System Information for Digital Television 
(informative). 

5. ATSC Standard A/57 (1996), Program/Episode/Version Identification (normative). 
[A/57 is being revised as of 5/31/00] 

6. ISO 639, Code for the Representation of Names of Languages, 1988 (informative). 

7. ISO CD 639.2, Code for the Representation of Names of Languages: aipha-3 code, 
Committee Draft, dated December 1994 (normative). 

8. ISO/IEC 10646-1:1993, Information technology — Universal Multiple-Octet Coded 
Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane 
(normative). 

9. ISO/IEC 8859, Information Processing — 8-bit Single-Octet Coded Character Sets, 
Parts 1 through 1 0 (normative). 

10. ITU-T Rec. H.222.0 | ISO/IEC 13818-1:1996, information Technology — Generic 
coding of moving pictures and associated audio — Part 1: Systems (normative). 

11. ITU-T Rec. H.262 j ISO/IEC 13818-2:1996, Information Technology — Generic 
coding of moving pictures and associated audio — Part 2: Video (normative). 

12. Digital Video Transmission Standard for Cable Television, SCTE DVS-031, Rev. 2, 
29 May 1997 (informative). 

13. EIA-708A Specification for Advanced Television Closed Captioning (ATVCC), 
Electronic Industry Association (normative). 

14. EIA-752 Specification for Transport of Transmission Signal Identifier (TSID) Using 
Extended Data Service), Electronic Industry Association {normative). 

15. Record of Test Results for Digital HDTV Grand Alliance System, September 8, 
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1995, Advanced Television Test Center (Informative). 

16. EIA-766 Specification for U.S. Region Rating Table (RRT) and Content Advisory 
Descriptor for Transport of Content Advisory Information Using ATSC A/65 
Program and System Information Protocol (PSIP), Electronic Industry Association 
{normative). 

3. DEFINITIONS 

3.1 Compliance Notation 

As used in this document, "shall" or "will" denotes a mandatory provision of the 
standard. "Should" denotes a provision that is recommended but not mandatory. "May" denotes 
a feature whose presence does not preclude compliance, that may or may not be present at the 
option of the implemented 

3.2 Acronyms and Abbreviations 

The following acronyms and abbreviations are used within this specification: 



ATSC 


Advanced Television Systems Committee 


bslbf 


bit serial, leftmost bit first 


BMP 


Basic Multilingual Plane 


CAT 


Conditional Access Table- 


CRC 


Cyclic Redundancy Check 


CVCT 


Cable Virtual Channel Table 


DTV 


Digital Television 


EPG 


Electronic Program Guide 


EIT 


Event Information Table 


EMM 


Entitlement Management Message 


ETM 


Extended Text Message 


ETT 


Extended Text Tabic 


GPS 


Global Positioning System 


PSIP 


Program and System Information Protocol 


MGT 


Master Guide Table 


MPAA 


Motion Picture Association of America 


MPEG 


Moving Picture Experts Group 


NVOD 


Near Video On Demand 


OOB 


Out of Band 


PAT 


Program Association Table 


PGR 


Program Clock Reference 


PES 


Packetized Elementary Stream 


pro 


Packet Identifier 


PMT 


Program Map Table 


PTC 


Physical Transmission Channel 


SCTE 


Society of Cable Telecommunications Engineers 
.4 . 
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TVCT 

unkode 
UTC 

uinisbf 
VCT 



SI 



STD 

STT 
rpchof 
RRT 
TS 



System Information 
System Target Decoder 
System Time Table 

remainder polynomial coefficients, highest order first 

Rating Region Table 

Transport Stream 

Terrestrial Virtual Channel Table 

Unicode™ 

Coordinated Universal Time' 

unsigned integer, most significant bit first 

Virtual Channel Table. Used in reference to either TVCT or CVCT. 



3.3 Definition of Terms 

The following terms are used throughout this document: 

descriptor: A data structure of the format; descriptorjag, descriptor jength. and a variable amount of 
data, The tag and length fields are each 8 bits. The length specifies the length of data that begins 
immediately following the descriptorjength field itself. A descriptor whose descriptorjag identifies a 
type not recognized by a particular decoder shall be ignored by that decoder. Descriptors can be 
included in certain specified places within PSIP tables, subject to certain restrictions (see Table 
6,16). Descriptors may be used to extend data represented as fixed fields within the tables. They 
make the protocol very flexible since they can be included only as needed. "New descriptor types 
can be standardized and included without affecting receivers that have not been designed to 
recognize and process the new types. 

digital channel: A set of one or more digital elementary streams. See virtual channel. 

event: A collection of elementary streams with a common time base, an associated start time, 
and an associated end time. An event is equivalent to the common industry usage of "television 
program." 

instance: See table instance, 
logical channel: See virtual channel. 

physical channel: A generic term to refer to the each of the 6-8 MHz frequency bands where 
television signals are embedded for transmission. Also known as the physical transmission 
channel (PTC). One analog virtual channel fits in one PTC but multiple digital virtual channels 
typically coexist in one PTC. 

physical transmission channel: See physical channel. 

program element: A generic term for one of the elementary streams or other data streams that 
may be included in a program. For example: audio, video, data, etc. 

program: A collection of program elements. Program elements may be elementary streams. 
Program elements need not have any defined time base; those that do have a common time base 



1 Since unanimous agreement could not be achieved by the iTU on using either the English word order, CUT, or the 
French word order, TUC, a compromise io use neither was reached. 
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are intended for synchronized presentation. The term program is also commonly used in the 
context of a "television program" such as a scheduled daily news broadcast. In this specification 
the term "event" is used to refer to a "television program" 10 avoid ambiguity. 

region; As used in this document, a region is a geographical area consisting of one or more 
countries. 

section: A data structure comprising a portion of an ISO/IEC 13818-1 defined table, such as the 
Program Association Table (PAT), Conditional Access Table (CAT), or Program Map Table 
(PMT). All sections begin with the tabiejd and end with the CRC_32 field, and their starting points 
within a packet payload are indicated by the pomter_?ieid mechanism defined in the ISO/IEC 
13818-1 International Standard. 

stream: An ordered series of bytes. The usual context for the term stream is the series of bytes 
extracted from Transport Stream packet payioads which have a common unique PSD value (e.g., 
video PES packets or Program Map Table sections). 

table: PSIP is a collection of tables describing virtual channel attributes, event features, and 
others. PSIP tables are compliant with the private section syntax of ISO/IEC 13818-1. 

table instance: Tables are identified by the tabiejd field. However, in cases such as the RRT and 
E3T, several instances of a table may be defmed simultaneously. All instances have the same PID 
and tabiejd but different tabiejd jsxtension, 

virtual channel: A virtual channel is the designation, usually a number, that is recognized by the 
user as the single entity that will provide access to an analog TV program or a set of one or more 
digital elementary streams. It is called "virtual" because its identification (name and number) 
may be defined independently from its physical location. Examples of virtual channels are: 
digital radio (audio only), a typical analog TV channel, a typical digital TV channel (composed 
of one audio and one video stream), multi-visual digital channels (composed of several video 
streams and one or more audio tracks), or a data broadcast channel (composed of one or more 
data streams). In the case of an analog TV channel, the virtual channel designation will link to a 
specific physical transmission channel. In the case of a digital TV channel, the virtual channel 
designation will link both to the physical transmission channel and to the particular video and 
audio streams within that physical transmission channel. 

3.4 Section and Data Structure Syntax Notation 

This document contains symbolic references to syntactic elements. Thc^e references are 
typographically distinguished by the use of a different lorn (e.g., re-itnete-d), may contain the 
underscore character (e.g., sequence_end_code) and may consist of chaiaucr strings that are not 
English words (e.g., dynrng). 

The formats of sections and data structures in this document are described using a C-like 
notational method employed in ISO/IEC 13818-1. 

4. DATA STRUCTURE 

This section describes the data structure common to all PSIP tables. It also lists valid 
tabiejd and PID values for every table that belongs to PSIP. 
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4,1 Tabie Format 

Tables defined in this Standard are structured in the same manner used for carrying 
ISO/IEC 13818-1 -defined PS! tables, shown in Table 4.1. The structure conforms to the generic 
private section syntax defined in ISO/IEC 13838-1 



Table 4.1 Table Format Used in PSIP 



Syntax 


Bits 


Format 


typical_PSI_table( ) { 






tabiejd 


8 


uimsbf 


sect!on_syntax_Jndicator 






privatejndicator 






reserved 


2 


■11" 


sectionjength 


12 


uimsbf 


tabSe_id_extensiori 




uimsbf 


Reserved 


2 


■11' 


yersion_number 


5 


uimsbf 


current_next_irid!cator 


1 


bslbf 


sectionjiurnber 


8 


uimsbf 


!ast_sectiors_jiismfoer 


8 


uimsbf 


protoco!_version 


8 


uimsbf 


actua!_tabie_data 






CRC_32 


32 


rpchof 



4,2 Table ID Ranges and Values 

Table 4.2 defines Tabie ID ranges and values. 
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Table 4,2 ID Ranges and Values 



Table ID 








Value (hex) 


Tables 


PID 


Ref. 




ISO/SEC 13818-1 Sections: 






0x00 


PROGRAM ASSOCIATION TABLE (PAT) 


0 


Ref. [10} 


0x0 1 


CONDITIONAL ACCESS TABLE (CAT) 


I 


Ref. [10] 


0x02 


TS PROGRAM MAP TABLE (PMT) 


pe. i A . 


Ref. [10] 


Ox03-Ox3F 


[ISO Reserved] 








User Private Sections: 






0x40-0x7F 


[User Private for other systems] 






0x80-0xBF 


[User Private] 








Other (Inniment*: 






0>CO 0xL6 










PSIP Tables: 






0xc7 


V>\--*} Rvil ID! I'wSl 1 (Mt-i) 


OxlFFB 


Sec.6.2 


0xC8 


1 L r.K- :v IsiAL V[R"U AL CHA v NJ£i iAb^E "VCT) 


OxIFFB 


Sec.6.3.1 


Q-Vj 


L MJ' ' Viki LA, -, - i , A3i I ( ( \ ( j i 


OxlFFB 


Sec.6.3.2 


OxCA 


,lA-<\(. p r (.T\ .AB. - CiR. ; 


OxlFFB 


Sec.6.4 


0-CB 


I WM VORViA''i>\ ■ AB. ■ U I") 


per MGT 


Sec.8.5 




-X^\D> OTrM "AP ! ; I ' i , 


per MGT 


Sec.6.6 




SYSTEM TIME TABLE (STT) 


OxlFFB 


Sec. 8.1 


OxCE-OxDF 1 | Reserved for future ATSC use] 






OxEO-OxE^ 








0\F6 U V F- 


[Reserved for future ATSC use] 






Ox- f 


! sue* -message h slier 







l able- defined in tint P IP Standard and an crcited as user extensions to it are 
considered *pn "lie" with respect to irO'LO^ I Tabic types 0x40 through OxBF are user 

defined t( ulside the *u pe of th-s PS?P SiindarcJ) 



4.3 Extensibility 

Ihe 1 blf p:otixo ! desuibes a nuMbc! of tables conveying system information and 
(.orient guide data Ntru^ures Iht Standaid is designed to be extensible via the following 
mechanisms: 

1. Reserved Fields: Fields in this Standard marked reserved shall be reserved for use 
either when revising this Standard, or when another standard is issued that builds 
upon this one. See Section 4.4 below. 

2. Standard Table Types: As indicated in Table 4.2, tabiejd values in the range OxCE- 
OxDF and 0xE6-0xFE shall be reserved for use either when revising this PSIP 
Standard, or when another standard is issued that builds upon this one. 

3. User Private Table Types: As indicated in Table 4.2, table Jd values in the range 
0x40 through OxBF shall be reserved for "user private" use. 

4. User Private Descriptors: Privately defined descriptors may be placed at designated 
locations throughout the tables described in this Standard. Ownership of one or more 
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user private descriptors may be indicated by the presence of an MPEG 
registraSiQn_descriptor(} preceding the descriptor(s). 

5. Protocol Version Field: Initially this field is set to 0, but after approval, future 
structural modifications shall be accommodated by defining different protocol version 
numbers. 

4.4 Reserved Fields 

reserved — Fields in this PSIP Standard marked "reserved" shall not be assigned by the user, but 
shall be available for future use. Decoders are expected to disregard reserved fields for which no 
definition exists that is known to that unit. Each bit in the fields marked "reserved" shall be set to 
one until such time as they are defined and supported, 

userjsrivate — Indicates that the bit or bit field is not defined within the scope of this Standard. 
The owner of the bit, and hence the entity defining its meaning, is derived via its context within a 
message. 

zero — Indicates that the bit or bit field shall have the value zero. 

5. TABLE HIERARCHY AND STRUCTURE REQUIREMENTS 

The Program and System Information Protocol (PSIP) is a collection of hierarchically 
arranged tables for describing system information and program guide data. These tables are 
packetized and multiplexed according to the transport protocol detailed in JSO/1EC 1381 8- 1 . 

The base PU) (base_PiD) is an explicitly defined value (0\ I FEB) used to identify the 
packets for the following tables for terrestrial and cable systems: The System Time Table (STT), 
the Master Guide Table (MGT), the Rating Region Table (RJIT), and the Virtual Channel Table 
(VCT). Several Event Information Tables (EIT) are also part of the PSIP data structures, with 
their PlDs explicitly defined in the MGT. Figure 5.1 illustrates the relations between these 
elements. 



.9. 
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Figure 5.1 Table HierarcSiy for the Program and System Information Protocol (PSIP) 

As the name indicates, the System Time Table (SIT) carries time information needed for 
any application requiring synchronization. The Rating Region Table (RRT) defines rating tables 
valid for different regions or countries. The Master Guide Table (MGT) defines sizes, PiDs, and 
version numbers for ail of the relevant tables. The Virtual Channel Table (VCT) actually exists in 
two versions: one for terrestrial and a second one for cable applications. Its purpose is to tabulate 
virtual channel attributes required for navigation and tuning. The terrestrial and cable versions 
are similar in structure, with the latter redefining the semantics of some fields pertinent to cable 
operations. 

Each of the Event information Tables (ElTs) lists TV programs (events) for the virtual 
channels described in the VCT. The ElTs are sequentially and chronologically organized from 
EVT-0 to HIT- 1 27. The first table (F.IT-0), corresponds to the currently valid list of events. The 
second table (E1T-1) corresponds to the next time window, and so on. 

During remultipicxing, LIT tables which originally existed in separate Transport Streams 
may be multiplexed into a common Transport Stream or \ice vena I- or this reason, it is very 
convenient to synchronize the start times and durations, of rhe FJ Ts. Consequently, the next three 
synchronization rules shall be followed when EIT tables are prepared. 

Requirement 1: Each EIT shall have a duration of 3 hours. 
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Requirement 2: Start times for EITs are restricted to 0:00 (midnight), 3:00, 6:00, 9:00, 
12:00 (noon), 15:00, 18:00 and 21:00. All of these times are UTC. 

Requirement 3: EIT-0 lists all of the available events for the current 3-hour time segment. 
EIT-I lists all of the available events for the next 3-hour time segment, and likewise, non- 
overlapping sequential time windows are allocated for all of the other EITs. 

For example, a broadcast group operating in the Eastern time zone of the U.S. at 15:30 
EDT (19:30 UTC) is required to cany EIT-0 describing events from 14:00 to 17:00 EDT (18:00 
to 21:00 in UTC time) plus EIT-1, EIT-2, and EIT-3 covering the next 9-hour interval between 
17:00 to 2:00 EDT. At 17:00 EDT, the first table, EIT-0, will be obsolete while EIT-1 will still 
be valid. At this time, simply by shifting the listed P!D values in the MGT, EIT-i becomes EIT-0 
and EIT-2 becomes EIT-1. Updating tables then becomes a process of shifting the list of PlDs in 
the MGT and their corresponding version numbers. However, updates and/or corrections to the 
information in the EITs may be performed at any time since the decoder monitors the MOT 
continuously, where the most current copy of the version number is maintained. Updates and/or 
corrections to the EST (other than shifting) shall be signaled by increasing the version number by 
one. 

Besides listing the PlDs for all of the EITs, the Master Guide Table (MGT) also lists a set 
of pids for Extended Text Tables (ETTs). The ETTs carry relatively long text messages for 
describing events and virtual channels. Each EIT has either zero or one associated ETT. 
Similarly, The VCT has either zero or one associated ETT. Figure 5.2 illustrates the concept. 



Figure 5.2 Extended Text Tables (ETTs) Defined to Carry Text Messages for Describing 
Virtual Channels and Events, 

5.1 Requirements for Terrestrial Broadcast 

The rules governing the transport of PSIP tables for terrestrial broadcast are: 

Requirement 4: Every digital Transport Stream in terrestrial broadcast shall include the 
SIT, the RRT, the TVCT, the MGT, and the first four Event Information Tables (EIT-0, 




MGT 



j for VCT 
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ElT-l, E1T-2 and EIT-3). All of the other EITs and the whole collection of ETTs are 
optional. 

Requirement 5: The PSIP tables shall describe all of the digital channels multiplexed in the 
Transport Stream. For convenience, the tables may optionally include information about 
analog channels as well as other digital channels available in different Transport 
Streams. 

5,2 Requirements for Cable 

The rules governing the transport of PSIP tables for cable are: 

Requirement 6; The required tables for a cable system are: the STT, the RRT, the CVCT, 
and the MGT. 

Requirement 1: The PSIP tables shall describe all of the digital channels multiplexed in the 
Transport Stream. For convenience, the tables may optionally include information about 
analog channels as well as other digital channels available in different Transport 
Streams. 

6. SPECIFICATIONS 

This chapter describes the bit stream syntax and semantics for the System Time Table 
(STT), Master Guide table (MGT), Virtual Channel Table (VCT), Rating Region Table (RRT), 
Event Information Table (KIT), Extended Text Table (ETT), core descriptors, and the multiple 
string structure. 

6.1 System Time Table (STT) 

The System Time Table provides the current date and time of day information. 
The following constraints apply to the Transport Stream packet carrying the STT: 

* P!D for STT shall have the value Ox I FFB (base_PlD) 

» transport_scrambling_control bits shall have the value '00' 

* adaptation_field_control bits shall have the value 6 0F 

The bit stream syntax for the System Time Table is shown in Table 6. 1 . 
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Table 6.1 Bit Stream Syntax for the System Time Table 



~JHL21^„ — -~- — -. . — — — — — — . 


Bit 

— — l JL_ 


F rm t 


system_ti!Tie_lab!'e_sectiGrs () { 






XaDi8_JCi 


8 




sectiors_syntax_indtcator 




'V 


privat© Jndicstor 




•r 


reserved 


2 




sectionjength 


12 


uimsbf 


table Jd_exterision 


16 


0x0000 


reserved 


2 


'11' 


version_nu ruber 




'00000' 


currersl_next_indicator 


1 


'1' 


section_nurrsber 


8 


0x00 


Sast_sectiori__number 


8 


0x00 


protocoi_version 


8 


uimsbf 


systemjime 


32 


uimsbf 


GPS_UTC_offset 


8 


uimsbf 


daylight savings 


16 


uimsbf 


for (l = 0;KN;!++){ 






descriptor^ 






} 

CRC 32 

} 


32 


rpchof 



tabiejd — This is an 8-bit field, which shall be set to OxCD, identifying this table as the System 
Time Table. 

section_syntax_indicator — This I -bit field shall be set to T. ft denotes that the section follows 
the generic section syntax beyond the section length field. 

privatejndicator — This 1-bit field shall be set to ' I '. 

sectionjength — 12-bit field specifying the number of remaining bytes in this section 
immediately following the sectionjength field up to the end of the section. The value of the 
sectionjength shall be no larger than 1021. 

tab!ejd_extension — This 16-bit Held shall be set to 0x0000. 

version_number — This 5-bit field shall have a value of zero. 

current_nextJndicator — This 1 -bit indicator is always set to T for an STT section; the STT sent 
is always currently applicable. 

sectionjiumber — The value of this 8-bit field shall always be 0x00 (this table is only one section 
long). 

!ast„section_rsumber — The value of this 8-bit field shall always be 0x00. 

protocoLversiors — An 8-bit unsigned integer field whose function is to allow, in the future, this 
table type to carry parameters that may be structured differently than those defined in the current 
protocol. At present, the only valid value for protocol_version is zero. Non-zero values of 
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protocoi_version may only be processed by decoders designed to accommodate the later versions as 
they become standardized, 

system jime — A 32-bit unsigned integer quantity representing the current system time as the 
number of GPS seconds since 12 am. January 6 iU , 1980. The count of GPS seconds and leap 
second count shall be accurate and correct to within plus or minus four seconds, as timed at the 
arrival in the decoder of the Transport Stream packet carrying the last byte of the CRC. 

GPS_UTC_offset — An 8-bit unsigned integer thai defines the current offset in whole seconds 
between GPS and UTC lime standards. To convert GPS time to UTC, ihe GPS_UTC_offset is 
subtracted from GPS time. Whenever the International Bureau of Weights and Measures decides 
that the current offset is too far in error, an additional leap second may be added (or subtracted), 
and the GPS_UTC_offset will reflect the change. 

dayiight_s3yirsgs — Daylight Savings T ime Control bytes. Refer to Annex A for the use of these 
two bytes. 

crc_32 — This is a 32-bit field that contains the CRC value that ensures a zero output from the 
registers in the decoder defined in Annex A of 1SO/IEC 13818-1 "MPEG-2 Systems" after 
processing the entire System Time Table section. 

6.2 Master Guide Table (MGT) 

The MGT lists version numbers, length in bytes, and PIDs for all of the PSIP tables with 
the exception of the STT which works independently from the other tables. 

The Master Guide Table is carried in a single section with table ID 0xC7, and obeys the 
syntax and semantics of the Private Section as described in Section 2.4.4.10 and 2.4.4.1 1 of 
1SO/1EC 13818-1. The following constraints apply to the Transport Stream packet (or packets) 
carrying the MGT: 

* PID for MGT shall have the value Ox I FFB (base_PID) 
» transport scrambling ..controi bits shall have the value '00" 

* adaptat!on_fie!d_control bits shall have the value '01' 

• payload. unit ..start., indicator of the Transport Stream packet carrying the tablejd field of 
the MGT section shall be 1 (first Transport Stream packet of the section) 

• poinferjieid of the Transport Stream packet carrying the tablejd field of the MGT 

section shall have the value 0x00 (section starts immediately after the pointer_field) 

The bit stream syntax for the Master Guide Table is shown in Table 6.2. 
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Table 6.2 Bit Stream Syntax for the Master Guide Table 



Syntax 


Bits 


Format 


master_guide_iabie_section () { 






tablejd 


8 


0xC7 


section syntax jrsdleator 




1 


privatejndicator 


1 


'1' 


reserved 


2 


'11' 


sectionjersgth 


12 


uimsbf 


tabSe_id_extension 


1o 


0x0000 


reserved 


2 


'11' 


versionjiumber 


5 


uimsbf 


current jiextjndicator 




T 


sectiorsnumber 


8 


0x00 


iast_s8ctiQn_number 


8 


0x00 


protocoi_version 


8 


uimsbf 


tabiesjiefined 


18 


uimsbf 


for (i=0;i<tables_defined;i++) { 






tabiejype 


16 


uimsbf 


reserved 


3 




tab!eJype„PfD 


13 


uimsbf 


reserved 


3 


'111' 


table Jype_yersiori_rsumfoer 


5 


uimsbf 




32 


uimsbf 


reserved 


4 


inr 


tabSe_type_descriptors_iength 


12 


uimsbf 


for(k=0;k<N;k++){ 






descriptor?,) 

} 






} 

reserved 


4 


'1111' 


descriptorsjength 


12 


uimsbf 


for(l = 0;l< N;l++){ 






descrfptorO 






} 

CRC 32 

} 


32 


rpchof 



tablejd — This is an 8-bit field which shall be set to 0xC7, identifying this table as the Master 
Guide Table. 

section_syntaxJndicator — This 1-bit field shall be set to 'I'. It denotes that the section follows 
the generic section syntax beyond the section length field. 

private jndicator — This S -bit field shall be set to ' 1' . 

sectiorsjength — 12-bit field specifying the number of remaining bytes in this section 
immediately following the section Jength field up to the end of the section. The value of the 
sectionjength shall be no larger than 4093. 

tablejd_extension — This 16-bit field shall be set to 0x0000. 
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versionjiumber — This 5-bit fieid is the version number of MGT. The version number shall be 
incremented by 1 modulo 32 when any field in the tabiejypes defined in the loop below or the 
MGT itself changes. 

ci!rrent„rsext_indicator — This 1-bit indicator is always set to T for the MGT section; the MGT 
sent is always currently applicable. 

section_number — The value of this 8-bit field shall always be 0x00 (this table is only one section 
long). 

iast_sectiors_number — The value of this 8-bit field shall always be 0x00. 

protocoS_¥ersiori — An 8-bit unsigned integer field whose function shall be to allow, in the future, 
this table type to carry parameters that may be structured differently than those defined in the 
current protocol. At present, the only valid value for protocoi_version is zero. Non-zero values of 
protocoi_version may only be processed by decoders designed to accommodate the later versions as 
they become standardized. 

tables_defiried — This 16-bit unsigned has a range of 6 - 370 (for terrestrial) and 2 - 370 for 
cable. 

table_type — This 16-bit unsigned integer specifies the type of table, based on Table 6.3. 



Table 6.3 Table Types 



t;sbie type 


Meaning 


0x0000 


Terrestrial VCT with current_next..indicasof=l 


0x000! 


Terrestrial VCT with current. :-■'.*>. i.-,Mv!-fi 


0x0002 


t Ath M 1 « ah e- i.'^L"- ■"'■>" - 5 


0.\0003 


Cable VCT with wnent.j*axi_indicator=0 


0x0004 


channel ETT 


OxOOOS-OxQOFF 


[Rt*trn-d far future A'i S( ;!«■! 


0x01 00-0x0 1 7F 


Hi i)U> Hi !r 


0x0 180-0x0 IFF 


[Reserved for fuitfre ATSC sssej 


0x0200-(}.n027F 


M«-ni I i i ■■!<!> .ii'iii bll-ir 


0x0280-0x0300 


1 Reserved for future ATSC use] 


0x0301 -0x03 FF 


RRT with rating,. ..region I -255 


0x0400-0xQFFF 


jliser private) 


OxlOOO-O.xFFFF 


j Reserved for future ATSC iisej 



table_type_P«D — This 1 3-bit field specifies the P!D for the tabiejype described in ihe loop. 

table_typ«..version_number — This ?-bit field reflects the version number of the isbtejype described 
in the loop. The value of this field shall be the same as the version_Humber entered in the 
corresponding fields of tables and table instances. For example, the value of this field for EIT-3 
will be the same as that of the veisionjiumber that appears in the actual FiT-3. The version number 
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for the next VCT (current_next_indicator = 0) shall be one unit more (moduio 32) than the version 
number for the current VCT (current_next_indicator = 1). 

numberjsytes — This 32-bit unsigned integer field indicates the total number of bytes used for the 
table jype described in the loop. 

iab!ejype_descriptorsjersgth — Total length of the descriptors for the tablejype described in the 
loop (in bytes). 

descriptorsjength — Total length of the MGT descriptor list that follows (in bytes). 

crc_32 — This is a 32-bit field that contains the CRC value that ensures a zero output from the 
registers in the decoder defined in Annex A of ISO/TEC 13818-1 "MPEG-2 Systems" after 
processing the entire Master Guide Table section. 

6,3 Virtual Channel Table (VCT) 

The Virtual Channel Table (VCT) contains a list of attributes for virtual channels carried 
in the Transport Stream. Any changes in the virtual channel structure shall be conveyed with a 
new version number. The basic information contained in the VCT table body includes Transport 
Stream ID, channel number (major and minor), short channel name, carrier frequency, program 
number, access controlled flag, location field for extended text messages, and service type. 
Additional information may be carried by descriptors which may be placed in the descriptor loop 
after the basic information. 

The Virtual Channel Table may be segmented into as many as 256 sections. One section 
may contain information for seyeral virtual channels, but the information for one virtual channel 
shall not be segmented and put into two or more sections. Thus for each section, the first field 
after protocol_version shall be num_channels_in_section. 

8.3.1 Terrestrial Virtual Channel Table 

The Terrestrial Virtual Channel Table is carried in private sections with table ID 0xC8, 
and obeys the syntax and semantics of the Private Section as described in Section 2.4.4. 1 0 and 
2.4.4. 1 1 of ISO/IEC 13818-1. The following constraints apply to the Transport Stream packets 
carrying the VCT sections: 

• pid for Terrestrial VCT shall have the value OxlFFB (base_P!D) 
e transport_scrambling_control bits shall have the value '00' 

• adaptation_field_control bits shall have the value '0 1 ' 

The bit stream syntax for the Terrestrial Virtual Channel Table is shown in Table 6.4, 

tabiejd — An 8-bit unsigned integer number that indicates the type of table section being defined 
here. For the terrestrial_virtual_channel_table_section(), the table jd shall be 0xC8. 

section_syritax_ indicator — The section_syntax_indicator is a one-bit field which shall be set to ' 1 ' for 
the terrestrial_virtual_channel_table_section(). 

privatejndicator — This 1-bit field shall be set to ' 1 '. 
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sectionjength — This is a twelve bit field, the first two bits of which shall be '00'. It specifies the 
number of bytes of the section, starting immediately following the sectionjength field, and 
including the CRC. The value in this field shall not exceed 1 02 ! . 

transport_str©amJd — The 16-bit MPEG-2 Transport Stream ID, as it appears in the Program 
Association Table (PAT) identified by a PID value of zero for this multiplex. The 
transport_stream_id distinguishes this Terrestrial Virtual Channel Table from others that may be 
broadcast in different PTCs. 
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Table 6,4 Bit Stream Syntax for the Terrestrial Virtual Channel Table 



Syntax 


Bits 


Format 


terrestrial_virtual_channel_table_section (} { 






tabie_id 


8 


0xC8 


sectiors _syrstax . Indicator 


1 


T 


privatejsidicator 


1 


T 


reserved 


2 


■ir 


sectionjength 


12 


uimsbf 


transport_stream_id 


16 


uimsbf 


reserved 


2 


'11' 


versiori_number 


5 


uimsbf 


current_rsextJndicator 


1 


bslbf 


section_number 


8 


uimsbf 


fast_section_niimber 


8 


uimsbf 


protocoi_version 


8 


uimsbf 


nunri_channeisJr!_section 


8 


iiimsbf 


for(i=0; i<num_channels_in_section; i++) { 






short_name 


7*16 


Unicode™ BMP 


reserved 


4 


'1111' 


major_chaiine!_niiinber 


10 


uimsbf 


mmor_ehannei__ruirnber 


10 


uimsbf 


moduiation_mode 


8 


uimsbf 


carrierjrequerscy 


32 


uimsbf 


charmei_TSID 


16 


uimsbf 


prograrri_number 


18 


uimsbf 


ETIVSJocation 


2 


uimsbf 


access_coritrolfed 


1 


bsibf 


hidden 


1 


bsSbf 


reserved 


2 


'11' 


hide guide 


1 


bsibf 


reserved 


3 


'111' 


service_type 


6 


uimsbf 


soisrcejd 


16 


uimsbf 


reserved 


6 


■111111" 


descriptors Sength 


10 


uimsbf 


fbr(i=0;i<N;i++){ 






descriptor^ 






} 

reserved 


6 




additioriai^descrsptorsjetigth 


10 




for(j=Q; j<N;j++) { 






additionaLdescriptor() 






CRC 32 

} 


32 


rpchof 



versiorwiumber — This 5 bit field is the version number of the Virtual Channel Table, For the 
current VCT (current_next_jfidicator ~ I), the version number shall be incremented by I whenever 
the definition of the current VCT changes. Upon reaching the value 3 1, it wraps around to 0. For 
the next VCT (current_next_indicator = 0), the version number shall be one unit more than that of the 



- 19- 



ATSC 



Rev. A to PS iP for Terrestrial Broadcast and Cable (A/65) 



5/31/00 



current VCT (also in modulo 32 arithmetic), In any case, the value of the version_number shall be 
identical to that of the corresponding entries in the MGT. 

currerstjiextjridicator — A one-bit indicator, which when set to ' 1' indicates that the Virtual 
Channel Table sent is currently applicable. When the bit is set to '0', it indicates that the table 
sent is not yet applicable and shall be the next table to become valid. 

sectiGswiiimber — This 8 bis field gives the number of this section The section jiumber of the first 
section in the Terrestrial Virtual Channel Table shall be 0x00 It shall be incremented by one 
with each additional section in the rerre-stnal Virtual Channel fable. 

fast_sectson_number — This 8 bit field specifies the number ol the la^t section (that is, the section 
with the highest section_'n.r<it.er,j of the complete Terrestrial Virtual Channel Table. 

protocoi_version — An 8-bit unsigned integer field whose function ss to allow, in the future, this 
table type to carry parameters that may be structured differently than those defined in the current 
protocol. At present, the only valid value for protocol_version is zero. Non-zero values of 
protocoLversion may only be processed by decoders designed to accommodate the later versions as 
they become standardized. 

riiim„channeis_iri„sect!ori — This 8 bit field specifies the number of virtual channels in this VCT 
section. The number is limited by the section length, 

short jiame — The name of the virtual channel, represented as a sequence of one to seven 16-bit 
character codes coded in accordance with the Basic Multilingual Plane (BMP) of Unicode™, as 
specified in ISO 10646-3. If the name of the virtual channel is shorter than seven Unicode™ 
characters, one or more instances of the null character value 0x0000 shall be used to pad the 
string to its fixed 14-byte length, 

major_channeL"umber — A 10-bit number that represents the "major" channel number associated 
with the virtual channel being defined in this iteration of the "for" loop. Each virtual channel 
shall be associated with a major and a minor channel number. The major channel number, along 
with the minor channel number, act as the user's reference number for the virtual channel. The 
major_channel_number shall be between 1 and 99. For major_channel_number assignments in the U.S., 
refer to Annex B. 

msnor_channeLnumber — A 10-bit number in the range 0 to 999 that represents the "minor" or 
"sub-" channel number. This field, together with major_channel_number, performs as a two-part 
channel number, where rninor_ehannel_number represents the second or right-hand part of the 
number. When the servicejype is analog television, minor_channei_number shall be set to 0, Services 
whose servicejype is either ATSC_digitalJelevision or ATSC_audio_oniy shall use minor numbers 
between 1 and 99. For other types of services, such as data broadcasting, valid minor virtual 
channel numbers are between 1 and 999 

modulatiori_mode — An 8-bit unsigned integer number that indicates the modulation mode for the 
transmitted carrier associated with this virtual channel. Values of modu!ation_mode are defined by 
this standard in Table 6.5. For digital signals, the standard values for modulation mode (values 
below 0x80) indicate transport framing structure, channel coding, interleaving, channel 
modulation, forward error correction, symbol rate, and other transmission-related parameters, by 
means of a reference to an appropriate standard. Values of moduiation_mode 0x80 and above are 
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outside the scope of ATSC, These may be used to specify non-standard modulation modes in 
private systems, A value of 0x80 for moduiation_mode indicates that modulation parameters are 
specified in a private descriptor. The moduiationjmode field shall be disregarded for inactive 
channels. 



Table 6.5 Modulation Modes 



modulation mode 


.Meaning 


0x00 




0x01 


Analog — The virtual channel is modulated using 
standard analog methods for analog television. 


0x02 


S€TE_a:K>de_l — The virtual channel has a 
symbol rm of S.0S7 Msps. transmitted in 
accordance with Digital Transmission Standard 
for Cable Television, Ref. f!2] (Mode 1). 
Typically, mode 1 will be used for 64-QAM. 


0x03 


SCTK_mode_2 i he virtual channel has n 

symbol" rate of 5.36 i Msps, transmitted in 
accordance with Digital Transmission Standard 
for Cable Television, Ref. [12] (Mode 2). 
Typically , mode 2 will be used for 256-QAM. 


0x04 


ATSC (8 VSB) — The virtual channel uses the 8- 
VSB modulation method conforming to the ATSC 
Digital Television Standard A/53. Ret. [2i. 


0x05 


ATSC (16 VSB) — The virtual channel uses the 
16- VSB modulation method conforming to the 
ATSC Digital Television Standard A/53. Ref. [2]. 


0x06-0\7F 


[Reserved for future u:e by ATSC] 


0x80 


Modulation parameters are defined by a private 
descriptor 


0x81-()vFF 


[User Private] 



carrier jreqsjency — A 32-bit unsigned integer that represents the carrier frequency associated with 
the analog or digital transmission associated with this virtual channel, in units of one Hz, For 
VSB-modulated signals, the given carrieMrequency represents the location of the pilot tone; for 
analog signals, it represents the frequency of the picture carrier. In the case of a digital terrestrial 
broadcast signal thai is transmitted at multiple carrier frequencies (via one or more translators), 
the carnerjrequency may be specified as zero. In such cases, the receiver is expected to associate 
the Transport Stream identified by the given transport. streamjd with the frequency tuned to 
acquire it, 

For the ATSC Digital Television Standard, where the PTC bandwidth is 6 MHz, the pilot tone is 
located 310 kHz 2 above the lower edge of the physical transmission channel, or 2.690 MHz 
below the specified center of the band. Similarly, for analog NTSC transmitted in the US, the 



2 This is the nominal value. To minimize interference for various combinations of nearby TV stations precision 
offsets of 19.403 kHz or 28.615 kHz may be used (See Ref. [15] page 1-3-15). The actual frequency may also shift 
due to the +/- 10 kHz offsets used in the NTSC assignments. 
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picture carrier is 1.25 MHz above the lower edge of the 6 MHz physical transmission charmei. 
The carrierjrequency field shall be disregarded for inactive channels. 

channeijTSSD — A 16-bit unsigned integer field in the range 0x0000 to OxFFFF that represents the 
MPEG-2 Transport Stream ID associated with the Transport Stream carrying the MPEG-2 
program referenced by this virtual channel. For inactive channels, channei_TSlD represents the ID 
of the Transport Stream that will carry ihe service when it becomes active. The receiver may use 
the channei_TSiD to verify that a Transport Stream acquired at the referenced carrier frequency is 
actually the desired multiplex. Analog signals may have a TSID provided that it is different from 
any DTV Transport Stream identifier; that is, it shall be truly unique if present. 3 A value of 
OxFFFF for channei_TSlD shall be specified for analog channels that do not have a valid TSID. 

prograrsij-iumber — A 16-bit unsigned integer number that associates the virtual channel being 
defined here with the MPEG-2 program association and TS program map tables. For virtual 
channels representing analog services, a value of OxFFFF shall be specified for program_number. 
For inactive channels (those not currently present in the Transport Stream), programjiumber shall 
be set to zero. This number shall not be interpreted as pointing to a Program Map Table entry. 

ETivsjocatior! — This 2-bit field specifies the existence and the location of an Extended Text 
Message (ETM), based on Table 6.6. 



Table 6.6 ETM Location 



ETM location 


Meaning 


0x00 


NolTM 


0x01 


LI VS louilca in tiie PIC driving itus PMP 


0x02 


ETM located in the PTC specified by the channel_TS10 


0x03 


!K.--..r.,->i u^^Ai sC ■:.■:] 



access„controSied — A 1-bit Boolean flag that indicates, when set, that the events associated with 
this virtual channel may be access controlled. When the flag is set to 0, event access is not 
restricted. 

hidden — A 1-bit Boolean flag that indicates, when set, that the virtual channel is not accessed by 
the user by direct entry of the virtual channel number. Hidden virtual channels are skipped when 
the user is channel surfing, and appear as if undefined, if accessed by direct channel entry. 
Typical applications for hidden channels are test signals and NVOD services. Whether a hidden 
channel and its events may appear in EPG displays depends on the state of the hide_guide bit. 

hide„guide — A Boolean flag that indicates, when set to 0 for a hidden channel, that the virtual 
channel and its events may appear in EPG displays. This bit shall be ignored for channels which 
do not have the hidden bit set, so that non-hidden channels and their events may always be 
included in EPG displays regardless of the state of the hide_guide bit. Typical applications for 
hidden channels with the hide_guide bit set to 1 are test signals and services accessible through 



3 A method to include such a unique 16-bit "Transmission Signal ID" in the NTSC VBI is specified in the E1A-752 
specification. 
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application-level pointers. 

An inactive channel is defined as a channel that has program guide data available, but the 
channel is not currently on the air. Inactive channels are represented as hidden channels with the 
hide_guide bit set to 0. The Transport Stream shall not carry a Program Map Table representing an 
inactive channel. 

servicejype — A 6-bit enumerated type field that identifies the type of service carried in this 
virtual channel, based on Table 6.7, 



Table 6.7 Service Types 



servke_tys>e 


Meaning 


0x00 
0x0! 


[Reserved] 

analog_television — The virtual channel carries analog television 
programming 


0x02 


ATSC_digitai_teiev!sion — The virtual channel carries television 
programming (audio, video and data) conforming to the ATSC Digital 
Television Standard 


0x03 


ATSC„audio_or!iy — The virtual channel conforms to the ATSC Digital 
Television Standard, and has one or more standard audio and data components 
but no video. 


0x04 


ATSG_data_broadcast_seivice — Conforming to the ATSC data broadcast 
standard under development by T3/S13. 


0x05-0x3F 


[Reserved for future ATSC use] 



sourcejd — A 16-bit unsigned integer number that identifies the programming source associated 
with the virtual channel, in this context, a source is one specific source of video, text, data, or 
audio programming. Source ID value zero is reserved. Source ID values in the range 0x0001 to 
OxOFFF shall be unique within the Transport Stream that carries the VCT, while values 0x1000 
to OxFFFF shall be unique at the regional level. Values for sourcejds 0x1000 and above shall be 
issued and administered by a Registration Authority designated by the ATSC. 

descriptorsjength — Total length ('in bytes) of the descriptors for this virtual channel that follows. 

additions* .descriptors .length Total length (in bytes) of the VCT descriptor list that follows. 

crc_32 — This is a 32-bit field that contains the CRC value that ensures a zero output from the 
registers in the decoder defined In Annex A of ISO/1EC 13818-1 "MPEG-2 Systems" after 
processing the entire Terrestrial Virtual Channel Table section. 

For inactive channels, the short_rsarr,e, rnajer_channel_number, and minor_channel_number fields reflect 
the name and channel number of the inactive channel, and may be used in construction of the 
program guide. The source_id for inactive channels is used, as it is for active channels, to link the 
virtual channel to the program guide data. The ETMjocaiion indicates, as it does for active 
channels, the location of text related to the virtual channel. The servicejype field and attribute 
flag access_consroiiea reflect the characteristics of the channel that will be valid when it is active, 
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6.3.2 Cable Virtual Channel Table 

The Cable Virtua! Channei Table is carried in private sections with table ID 0xC9, and obeys the 
syntax and semantics of the Private Section as described in Section 2.4.4.10 and 2.4.4.11 of 
ISO/TEC 13818-1. The following constraints apply to the Transport Stream packets carrying the 
VCT sections: 

* PID for Cable VCT shall have the value OxlFFB (base_PID) 

* transport_scrambling_control bits shall have the value '00' 

* adaptation Jieldjxmtroi bits shall have the value 'OF 

The bit stream syntax for the Cable Virtual Channel Table is shown in Table 6.8. The semantics 
for the CVCT are the same as the TVCT except for those fields explicitly defined below. 

tabiejd — An 8-bit unsigned integer number that indicates the type of table section being defined 
here. For the cable_VCT_section, the table Jd shall be 0xC9. 

major_chan!te!_number — A 10-bit number in the range ! to 999 that represents the "major" virtual 
channel number associated with the virtual channel being defined in this iteration of the "for" 
loop. Each virtual channel must be associated with a major and a minor virtual channel number. 
The major virtual channel number, along with the minor virtual channel number, act as the user's 
reference number for the virtual channel. 

minor_channeL""f"ber — A 10-bit number in the range 0 to 999 that represents the "minor" or 
"sub-" virtual channel number. This field, together with major_channel_number, performs a two-part 
virtual channei number, where minor_channe!_nurriber represents the second or right-hand part of the 
number 
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Table 6.8 Bit Stream Syntax for the Cable Virtual Channel Table 



Syntax 


Bits 


Format 


cable_virtual_channel_table_section () { 






labiejd 


8 


0xC9 


sectiorsjsyntaxjndicator 


1 


'1' 


privatejndicator 


1 


T 


reserved 


2 


'11' 


seetionjenglh 


12 


uimsbf 


tran$port_streamjd 


16 


uimsbf 


reserved 


2 


'11' 


versi0n_number 


5 


uimsbf 


curreritjiextjrsdicator 


1 


bsibf 


seetion_number 


8 


uimsbf 


iast_sectior!_number 


8 


uimsbf 


protocoLversion 


8 


uimsbf 


fium__charjne!s_!n__sect!On 


8 


uimsbf 


for(i=0; i<num_channels_in_section;i++) { 






short_name 


7*16 


Unicode™ BMP 


reserved 


4 


'1111' 


major_chanrief_number 


10 


uimsbf 


mirior_cbannel_number 


10 


uimsbf 


modulation mode 


8 


uimsbf 


carrierjreqiiersey 


32 


uimsbf 


chars nel_TSID 


16 


uimsbf 


program_number 


16 


uimsbf 


ETiVHoGafion 


2 


uimsbf 


access_corstroiSecS 


1 


bsibf 


hidden 


1 


bslbf 


path_seiecl 


1 


bsibf 


out of band 


1 


bslbf 


hide guide 


1 


bsibf 


reserved 


3 


'111' 


servieejype 


6 


uimsbf 


sourcejd 


16 


uimsbf 


reserved 


6 


'111111' 


descriptors iength 


10 


uimsbf 


for (i=0;i<N;i++) { 






descriptor(5 






} 

reserved 


6 


'111111' 


addstionai_descriptorsJength 


10 


uimsbf 


for(j=0; j<N;j++) { 






additionai_descriptor{) 






} 

CRC 32 

} 


32 


rpchof 



pathjselect — A 1-bit field that associates the virtual channel with a transmission path. For the 
cable transmission medium, path_seiect identifies which of two physical input cables carries the 
Transport Stream associated with this virtual channel. Table 6.9 defines path_seiect, When the 
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channel is inactive, path_seiect shall reflect the characteristics of the channel that will be valid 
when it is again active. 
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Table 6.9 Path Select 



path selec 


l | Meaning 


0 


1 path ! 


1 p,Hh 2 



out_of_barid — A Boolean flag that indicates, when set, that the virtual channel defined in this 
iteration of the "for" loop is carried on the cable on an out-of-band physical transmission channel 
whose frequency is indicated by carrier Jrequency. When clear, the virtual channel is carried within 
a standard tuned multiplex at that frequency. When the channel is inactive, oiit_of_band shall 
reflect the characteristics of the channel that will be valid when it is again active. 

sourcejd — A 16-bit unsigned integer number that identifies the programming source associated 
with the virtual channel. In this context, a source is one specific source of video, text, data, or 
audio programming. Source FD value zero is reserved to indicate that the programming source is 
not identified. Source ID values in the range 0x0001 to OxOFFF shall be unique within the 
Transport Stream that carries the VCT, while values 0x1000 to OxFFFF shall be unique at the 
regional level. Values for sourcejds 0x1000 and above shall be issued and administered by a 
Registration Authority designated by the ATSC. 

6.4 Rating Region Table (RRT) 

The Rating Region Table (RRT) carries rating information for multiple geographical regions. 
Each RRT instance, identified by ratirig_region (the 8 least significant bits of tabie_id_extension), 
conveys the rating system information for one specific region. The size of each RRT instance 
shall not be more than 1024 bytes (including section header and trailer), and it shall be carried by 
only one MPEG-2 private section. 

The following constraints apply to the Transport Stream packets carrying the RRT sections. 

» PID shall have the value OxlFFB (base_PiD) 

» transport_scrambling_control bits shall have the value '00' 

• adaptation_field_control bits shall have the value '01 ' 

The bit stream syntax for the Rating Region Table is shown in Table 6.10. 

tabiejd — This is an 8-bit field, which shall be set to OxCA, identifying this table as the Rating 
Region Table (RRT). 

sectior!_syrstax.Jridicator — This 1-bit field shall be set to T. It denotes that the section follows 
the generic section syntax beyond the section length field. 

privatejrsdicator — This 1 -bit field shall be set to ' 1 ' . 

section jength — i 2-bit field specifying the number of remaining bytes in this section 
immediately following the section jength field up to the end of the section. The value of the 
sectionjength shall be no larger than 1021. 
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Table 6.10 Bit Stream Syntax for the Rating Region Table 



Syntax 


Bits 


Format 


rating_region_table_section () { 






tabiejd 


8 


OxCA 


section_syntaxJndicator 


1 


'1' 


privatejndicator 


i 


T 


reserved 


2 


•ir 


seetionjength 


12 


uimsbf 


table_id_extension { 






reserved 


8 


OxFF 


rating region 

} 


8 


uimsbf 


reserved 
version_number 


2 
5 


uimsbf 


eurrent_nextjndicator 


1 


T 


section_number 


8 


uimsbf 


iast_sect!on_number 


8 


uimsbf 


protocof_versior! 


8 


uimsbf 


rating_region_nameJength 


8 


uimsbf 


ra t i rs g_re g i o rs _n a m e_te xt{) 


var 




dsmensions_defsned 


3 


uimsbf 


for{i=0; i<dirriensioris_defined;s++) { 






dimefisiori_name_iength 


8 


uimsbf 


dimefision_name_text(} 


var 




reserved 


3 


'111' 


graduated_scaie 




bsibf 


values_defir!ed 


4 


uimsbf 


for (j=0;i<va!ues_defineci;j ++) { 






abbrev_ratirsg_vaiuejength 


8 


uimsbf 


abbrev_rating_vaSue_ text{) 


var 




ratirsg^yaiuejersgth 


8 


uimsbf 


rating vaiise text() 

} 






) 

reserved 




'11111V 


descriptors length 


10 


uimsbf 


for (i=0;i<N;i++) { 






descriptors.) 






} 

CRC 32 

} 


32 


rpchof 



rating_reg'!ori — An 8-bit unsigned integer number that defines the rating region to be associated 
with the text in this rating_regionjable_section(). The value of this field is the identifier of this rating 
region, and thus this field may be used by the other tables (e.g. MGT) for referring to a specific 
rating region table. Values of rati ng_reg ion are defined in Table 6.1 1. 
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Table 6.11 Rating Regions 



rating_region 


Ralisig Region IN asise 


0x00 


i Forbidden 


0x01 


] US {50 states + possessions) 


0x02-0xFF 


! [Reserved] " 



versionjiumber — This 5-bit field is the version number of the Rating Region tabic identified by 
combination of the fields tablejd and table_id_extension. The version number shali be incremented 
by i modulo 32 when any field in this instance of the Rating Region Table changes, The value of 
this field shali be the same as that of the corresponding entry in MGT. 

curreni„nexUrid!'cator — This 1 -bit indicator is always set to ' 1'. 

section„number — The value of this 8-bit field shall always be 0x00. 

iast_sectiori_rsumber — The value of this 8-bit field shall always be 0x00. 

protocoLversiori — The value of this 8-bit field shall always be 0x00. 

rating_region_name_iength — An 8-bit unsigned integer number that defines the total length (in 
bytes) of the rating_region_name_text() field to follow. 

rating_region_name_text() — A data structure containing a multiple string structure which 
represents the rating region name., e.g. "U.S. (50 states + possessions)", associated with the value 
given by rating_region. Text strings are formatted according to the rules outlined in Section 6.8. 
The display string for the rating region name shall be limited to 32 characters or less. 

dimerssions^defined — This 8-bit field (1-255) specifies the number of dimensions defined in this 
rating_region_table_section(). 

dimension„rsameJength — An 8-bit unsigned integer number that defines the total length in bytes 
of the dimension_name_text() field to follow. 

dimens!on_name_text() — A data structure containing a multiple string structure which represents 
the dimension name being described in the loop. One dimension in the U.S. rating region, for 
example, is used to describe the MPAA list. The dimension name for such a case may be defined 
as "MPAA". Text strings are formatted according to the rules outlined in Section 6.8. The 
dimension name display string shall be limited to 20 characters or less. 

graduated_seale — This 1-bit flag indicates whether or not the rating values in this dimension 
represent a graduated scale, i.e., higher rating values represent increasing levels of rated content 
within the dimension. Value 1 means yes, while value 0 means no. 

va!ues_defined — This 4-bit field (1-15) specifies the number of values defined for this particular 
dimension. 

abbrev_fating_vaiueje!igth — An 8-bit unsigned integer number that defines the total length (in 
bytes) of the abbrev_rating_value_text() field to follow. 

abbrev_raling__vaiue_text() — A data structure containing a multiple string structure which 
represents the abbreviated name for one particular rating value. The abbreviated name for rating 
value 0 shall be set to a null string, i.e., "". Text strings are formatted according to the rules 
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outlined in Section 6.8. The abbreviated value display string shall be limited to 8 characters or 
less. 

rating_vaiuejength — An 8-bit unsigned integer number that defines the total length (in bytes) of 
the rating_vaiue_text() field to follow. 

ratifig_va!ue_text{) — A data structure containing a muitiple string structure which represents the 
full name for one particular rating value. The full name for rating value 0 shall be set to a nuli 
string, i.e., "". Text strings are formatted according to the rules outlined in Section 6.8. The rating 
value display string shall be limited to 150 characters or less. 

descriptorsjersgth — Length (in bytes) of all of the descriptors that follow this field. 

crc_32 — This is a 32-bit field that contains the CRC value that ensures a zero output from the 
registers in the decoder defined in Annex A of ISO/IEC 13818-1 "MPEG-2 Systems" after 
processing the entire Rating Region Table section. 

6.5 Event information Table (BIT) 

The Event Information Table (EIT) contains information (titles, start times, etc.) for 
events on defined virtual channels. An event is, in most cases, a typical TV program, however its 
definition may be extended to include particular data broadcasting sessions and other information 
segments. Up to 128 EITs may be transmitted and each of them is referred to as EIT-k, with k = 
0,1,... 127. 

Each EIT-k can have muitiple instances, each of which contains information for one 
virtual channel, and each of which is identified by the combination of table jd and sourcejd. Each 
EIT-k instance may be segmented into as many as 256 sections. One section may contain 
information for several events, but the information for one event shall not be segmented and put 
into two or more sections. Thus the first field after protoco!_version for each section shall be 
num_events_in_section. 

PSIP supports up to 128 EITs, each of which provides the event information for a certain 
time span. For terrestrial broadcast, at least the first four EITs shall be included in the Transport 
Stream. Any event programmed for a time interval that extends over one or more EITs shall be 
described in each of these EITs, with the same eventjd. For instance, an event that starts at 17:30 
UTC and lasts until 19:30 UTC will appear in two EITs with the same eventjd, the EST covering 
15:00-18:00 (UTC) as well as the EIT covering 18:00-21:00 (UTC). For a particular virtual 
channel, an eventjd identifies uniquely each of the events programmed for the 3-hour interval of 
an EIT. 

Each virtual channel defined in the VCT shall have a corresponding instance of EIT-k, 
unless the virtual channel belongs to a group sharing the same sourcejd. Virtual channels sharing 
a sourcejd appear in applications such as NVOD. In such a case, the entire group will have a 
unique instance of EIT-k identified precisely by the sourcejd. If a virtual channel has no event in 
the time span covered by EIT-k, its corresponding EIT instance shall have only one section, and 
the field num_eventsJn_section shall be set to zero. 

Events shall be in the order of their starting times, i.e., the start time of the first event 
shall be ahead of that of the second event, and the start time of the last event in section one shall 
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be equal or less than that of the first event in section two with the equality holding only when 
both events are the same. 

For NVOD services, event entries in the EIT correspond to events scheduled in the virtual 
channel that carry the time_shifted_descriptor (the reference virtual channel). However, an 
NVOD event shall be listed in applicable EITs even when the NVOD event has finished in the 
reference virtual channel as long as the NVOD event remains on the air as a time shifted service 
in complementary virtual channels. Hence, an EIT may contain, in some cases, an expired event 
describing NVOD services. 

The Event Information Table is carried in private sections with table ID OxCB, and obeys 
the syntax and semantics of the Private Section as described in Section 2.4.4.10 and 2.4.4.1 1 of 
ISO/IEC 13818-1. The following constraints apply to the Transport Stream packets carrying the 
EIT sections: 

* PID for EIT-k shall have the same value as specified in the MGT, and shall be unique 
among the collection of table_type_PlD values listed in the MGT. 

* transport_scrambling_control bits shall have the value '00'. 

* adaptation_field_control bits shall have the value "01 '. 

The bit stream syntax for the Event Information Table is shown in Table 6.12. 

tabiejd — This is an 8-bit field which shall be set to OxCB, identifying this section as belonging 
to the Event Information Table. 

section„syntaxjndicator — This 1-bit field shall be set to M \ It denotes that the section follows 
the generic section syntax beyond the section length field. 

privatejndicator — This 1 -bit field shall be set to 1 1 '. 

section Jength — 12-bit field specifying the number of remaining bytes in this section 
immediately following the sectionjength field up to the end of the section, including the CRC_32 
field. The value of this field shall not exceed 4093. 

sourcejd — This 16-bit field specifies the sourcejd of the virtual channel carrying the events 
described in this section. 

version_number — This 5-bit field is the version number of EIT-i. The version number shall be 
incremented by 1 modulo 32 when any field in the EIT-i changes. Note that the version_number for 
EIT-i has no relation with that for EIT-j when j is not equal to i. The value of this field shall be 
identical to that of the corresponding entry in the MGT. 

current_next_indicator — This 1-bit indicator is always set to T for EIT sections; the EIT sent is 
always currently applicable. 

section_number~— This 8-bit field gives the number of this section. 

!ast„sectior!_number — This 8-bit field specifies the number of the last section. 

protocoLversiors — An 8-bit unsigned integer field whose function is to allow, in the future, this 
table type to carry parameters that may be structured differently than those defined in the current 
protocol. At present, the only valid value for protocoi_version is zero. Non-zero values of 
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protoco!_version may only be processed by decoders designed to accommodate the later versions as 
they become standardized. 



Table 6,12 Bit Stream Syntax for the Event Information Table 



Sy!st i x . „. „. 




Format 


event_inforrnation_table_section {} { 






tablejd 


8 


OxCB 


section_syfstaxjndicator 




'1' 


privatejndicator 


1 


'1' 


reserved 


2 


'11' 


sectsonjersgth 


12 


uimsbf 


sourcejd 


16 


uimsbf 


zero 


2 


'00' 


version_number 


5 


uimsbf 


currentjiextjndicator 


1 




seetionjiumber 


8 


uimsbf 


!ast_sect!on_rsumber 


8 


uimsbf 


protoco!_vers[on 


8 


uimsbf 


num_eventsjr!_section 


8 


uimsbf 


for (j = 0; j< num_events_in_section;j++) { 






reserved 






eventjd 


14 


uimsbf 


startjime 


32 


uimsbf 


reserved 


2 


'11' 


ETSVSJocation 


2 


uimsbf 


fersgth iri__seconds 


20 


uimsbf 


titlejengih 


8 


uimsbf 


title Jext() 






rest-rved 


4 


'1111' 


descriptors Jength 


12 




for(i=0;i<N;i++){ 






descriptorf) 

} 






} 

CRC 32 

} 


32 


rpchof 



num_eyentsjri_sectior! — Indicates the number of events in this EIT section. Value 0 indicates no 
events defined in this section. 

eventjd — This field specifies the identification number of the event described. This number will 
serve as a part of the event ETMjd (identifier for event extended text message). 

startjime — A 32-bit unsigned integer quantity representing the start time of this event as the 
number of GPS seconds since 12 am, January 6 th , 1980. 

eTB/Mocation — - This 2-bit field specifies the existence and the location of an Extended Text 
Message (ETM), based on Table 6.13 
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Table 6.13 ETM Location 



ETM location 


Meaning 


0x0 


No ETM 


0x1 


ETM located in the PTC carrying this PSIP 


0x2 


ETM iocated in the PTC carrying this event 


0x3 


[Reserved for future ATSC use] 



Seogth_in_seconds — Duration of this event in seconds, 

title ..length - This field specifies the length (in bytes) of the titie_text(). Value 0 means that no title 
exists for this event. 

titiejextO — The event title in the format of a multiple string structure (see Section 6.8). 

descriptors jength — Total length (in bytes) of the event descriptor list that follows. 

crc_32 — This is a 32-bit field that contains the CRC value that ensures a zero output from the 
registers in the decoder defined in Annex A of ISO- 138 18-1 "MPEG-2 Systems" after processing 
the entire Event Information Table section. 

6.6 Extended Text Table (ETT) 

The Extended Text Table (ETT) contains Extended Text Message (ETM) streams, which 
are optional and are used to provide detailed descriptions of virtual channels (channel ETM) and 
events (event ETM). An ETM is a multiple string data structure (see Section 6.8), and thus, it 
may represent a description in several different languages (each string corresponding to one 
language). If necessary, the description may be truncated to fit allocated display space. 

Within a Transport Stream, the Extended Text Message is carried on a private section 
with table SD OxCC. Each description is distinguished by its unique 32-bit ETMj'd immediately 
after the field protocol_version. This allows the receiver to search for a single description quickly 
without having to parse the payioad of a large table. 

The ETT section for a virtual channel or an event is carried in the home physical 
transmission channel (the physical transmission channel carrying that virtual channel or event) 
with PID specified by the field tabie_type_P!D in corresponding entries in the MGT. This specific 
PID is exclusively reserved for the ETT stream. 

The following constraints apply to the Transport Stream packets carrying the ETT 
sections. 

• PID for ETT shall have the same value as the field table_type_PlD in corresponding 
entries in the MGT, and shall be unique among the collection of tab(e_type_PiD values 
listed in the MGT. 

• transport_scrambling_control bits shall have the value 6 00 ! 

• adaptationjield_control bits shall haye the value '01 ' 



The bit stream syntax for the Extended Text Table is shown in Table 6,14. 
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Table 6.14 Bit Stream Syntax for the Extended Text Table 



Syntax 


Bits 


Format 


extended_text_table_section () { 






tablejd 


8 


OxCC 


section_syntax_mdicator 




'1' 


privatejndicator 




T 


reserved 


2 


'11' 


sectionjength 


12 


uimsbf 


tab!e_id__©xtensiGrs 


16 


0x0000 


reserved 


2 


'11' 


versiors^riumber 




uimsbf 


curreni_ri8Xt_mdicator 


1 




seetion_riumber 


8 


0x00 


last_sectiori_number 


8 


0x00 


protocoLversion 


8 


uimsbf 


ETlV1_id 


32 


uimsbf 


extended_text_message Q 


var 




CRC_32 


32 


rpchof 



tabiejd — Identifies this section as belonging to a Extended Text Table. (OxCC) 

section_syntax_indicator — This 1-bit field shall be set to T. It denotes that the section follows 
the generic section syntax beyond the section length field. 

privatejndicator — This 1-bit field shall be set to ' 1 '. 

sectionjength — 12-bit field specifying the number of remaining bytes in the section immediately 
following the sectionjength field up to the end of the section. The value of the sectionjength shall 
be no larger than 4093. 

table jd_extension — This 16-bit field shall be set to 0x0000. 

version_number — For the channel ETT, this 5-bit field indicates the version number of the 
channel ETT. The version number shall be incremented by 1 modulo 32 when any ETM in the 
channel ETT changes. For event ETT, this 5-bit field indicates the version number of event ETT- 
i, where i, as in the EIT case, is the index of time span. The version number shall be incremented 
by 1 modulo 32 when any ETM in the event ETT-i changes. Note that the version_number for event 
ETT-i has no relation with that for event ETT-j when j is not equal to i. The value of this field 
shall be identical to that of the corresponding entry in the MGT. 

current_fsextjfidicator — This 1 -bit indicator is always set to ' 3 ' for ETT sections; the ETT sent is 
always currently applicable. 

section„number — The value of this 8-bit field shall always be 0x00 (this table is only one section 
long). 

lastjsection^number — The value of this 8-bit field shall always be 0x00. 

protocoLversion — An 8-bit unsigned integer field whose function is to allow, in the future, this 
table type to carry parameters that may be structured differently than those defined in the current 
protocol. At present, the only valid value for protocoi_version is zero. Non-zero values of 
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protocoi_version may only be processed by decoders designed to accommodate the later versions as 
they become standardized, 

ETM_id — Unique 32-bit identifier of this extended text message. This identifier is assigned by 
the rule shown in Table 6.15. 

Table 6,15 ETM ID 



ehannei ETM Jd 



event ETM_id 



extended jext„message{) — The extended text message in the format of a multiple string structure 
(see Section 6.8). 

CRC_32 — This is a 32-bit field that contains the CRC value that ensures a zero output from the 
registers in the decoder defined in Annex A of ISO- 5 381 8-1 "MPEG-2 Systems" after processing 
the entire Transport Stream ETT section. 



6.7 Core Descriptors 

Table 6.16 lists all of the core descriptors and their descriptor tags. The Service location 
descriptor shall always be present in the terrestrial VCT (shown with an "S"). When present, 
some descriptors shall be in each indicated location (shown with an "M"). Some descriptors also 
may be present in a second location within either the terrestrial or the cable case (shown with an 
"O"). Asterisks mark the tables where the descriptors may appear without restrictions. The range 
of MPEG-2-defmed or reserved descriptor tags is between 0x02 and 0x3F plus OxFF. 



Table 6,16 List of Descriptors for PSIP Tables. 



Descriptor Name 


Descriptor 
tag 


Terrestrial 


Cable 


PMT 


MGT 


VCT 


EIT 


PMT 


MGT 


VCT 


EIT 


stuffing descriptor 


0x80 


















AC-3 audio descriptor 


0x81 








M 


M 






O 


caption service 
descriptor 


0x86 


O 






M 


M 






O 


content advisory 
descriptor 


0x87 


O 






M 


M 






0 


extended channel name 
descriptor 


OxAO 






M 








M 




service location 
descriptor 


OxAl 






S 








M 




time-shifted service 
descriptor 


0xA2 






M 








M 




component name 
descriptor 


0xA3 


M 








M 








user private 


OxCO-OxPE 
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6.7.1 AG-3 Audio Descriptor 

The AC-3 audio descriptor, as defined in Ref, [I] and constrained in Annex B of Ref. [2] 
, may be used in the PMT and/or in EITs. 

6.7.2 Program Identifier Descriptor 

The program_identifier_descriptor, as defined in Ref. [5], shall not be used in any PS1P 
descriptor loops. 

6.7.3 Caption Service Descriptor 

The caption service descriptor provides closed captioning information, such as closed 
captioning type and language code for events with closed captioning service, This descriptor 
shall not appear on events with no closed captioning service. 

The bit stream syntax for the closed captioning service descriptor is shown in Table 6. 1 7. 



Table 6,17 Bit Stream Syntax for the Caption Service Descriptor 



Syntax 


Bits 


Format 


captlori__service_descriptor () { 






descriptorjag 


8 


0x86 


descriptorjength 


8 


uimsbf 


reserved 


3 


'111' 


rsumber_Gf_services 


5 


uimsbf 


for (i=0;i<number_of_services;i++S { 






Sarsguage 


8*3 


uirrisbf 


ccjype 


1 


bsibf 


reserved 


1 


T 


if (cc_type==line21) { 






reserved 


5 


'11111' 


VmeZi fieid 


1 


bsibf 


} 

eise 






captiors__serviee_rs!jmber 




uimsbf 


easy_reader 




bsibf 


wide_aspect_ratio 


1 


bsibf 


reserved 

} 

} 


14 


'11111111111111' 



descriptorjag — An 8-bit field that identifies the type of descriptor. For the 
caption_service_descriptor() the value is 0x86. 

descriptorjength — An 8-bit count of the number of bytes following the descriptorjength itself. 

rsumber _0f_serviees — An unsigned 5-bit integer in the range 1 to 16 that indicates the number of 
closed caption services present in the associated video service. Note that if the video service does 
not carry television closed captioning, the caption_service_descriptor() shai! not be present either in 
the Program Map Table or in the Event Information Table. 
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Each iteration of the "for" loop defines one closed caption service present as a sub-stream within 
the 9600 bit per second closed captioning stream. Each iteration provides the sub-stream's 
language, attributes, and (for advanced captions) the associated Service Number reference. Refer 
to Ref. [13] for a description of the use of the Service Number field within the syntax of the 
closed caption stream. 

language — A 3-byte language code per ISO 639.2/B (Ref. [7]) defining the language associated 
with one closed caption service. The lSO_639_language_code field contains a three-character code 
as specified by ISO 639.2/B. Each character is coded into 8 bits according to ISO 8859-1 (ISO 
Latin- \) and inserted in order into the 24-bit field. 

ccjype — A flag that indicates, when set, that an advanced television closed caption service is 
present in accordance with Ref. [13]. When the flag is clear, a line-21 closed caption service is 
present. For line 21 closed captions, the Hne2i_fieid field indicates whether the service is carried in 
the even or odd field. 

!ine2i_fseid — A flag that indicates, when set, that the line 21 closed caption service is associated 
with the field 2 of the NTSC waveform. When the flag is clear, the line-21 closed caption service 
is associated with field i of the NTSC waveform. The iine2l_fseid flag is defined only if the ccjype 
flag indicates line-21 closed caption service. 

caption^service^number — A 6-bit unsigned integer value in the range zero to 63 that identifies the 
Service Number within the closed captioning stream that is associated with the language and 
attributes defined in this iteration of the "for" loop. See Ref. [13] for a description of the use of 
the Service Number. The caption_service_number field is defined only if the ccjype flag indicates 
closed captioning in accordance with Ref. 1 13]. 

easyjeader — A Boolean flag which indicates, when set, that the closed caption service contains 
text tailored to the needs of beginning readers. Refer to Ref. [13] for a description of "easy 
reader" television closed captioning services. When the flag is clear, the closed caption service is 
not so tailored. 

wde_aspect_ratio — A Boolean flag which indicates, when set, that the closed caption service is 
formatted for displays with 16:9 aspect ratio. When the flag is clear, the closed caption service is 
formatted for 4:3 display, but may be optionally displayed centered within a 16:9 display. 

6.7.4 Content Advisory Descriptor 

The Content Advisory Descriptor is used to indicate, for a given event, ratings for any or 
ail of the rating dimensions defined in the RRT (Rating Region Table). Ratings may be given for 
any or all of the defined regions, up to a maximum of 8 regions per event. An Event without a 
Content Advisory Descriptor indicates that the rating value for any rating dimension defined in 
any rating region is zero. The absence of ratings for a specific dimension is completely 
equivalent to having a zero-valued rating for such a dimension. The absence of ratings for a 
specific region implies the absence of ratings for all of the dimensions in the region. The absence 
of a Content Advisory Descriptor for a specific event implies the absence of ratings for ail of the 
regions for the event. 

The bit stream syntax for the Content Advisory Descriptor is shown in Table 6, 1 8. 
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descriptorjag — This 8-bit unsigned integer shali have the value 0x87, identifying this descriptor 
as content_acivisory_descriptor. 

descriptor jersgth — This 8-bit unsigned integer specifies the length (in bytes) immediately 
foliowing this field up to the end of this descriptor. 

raii!ig_region_cour!t — A 6-bit unsigned integer value in the range 1 to 8 that indicates the number 
of rating region specifications to follow. 

raiiag„region — An unsigned 8-bit integer that specifies the rating region for which the data in the 
bytes to follow is defined. The rating_region associates ratings data given here with data defined in 
a Ratings Region Table tagged with the corresponding rating region. 

rated_dimenssons — An 8-bit unsigned integer field that specifies the number of rating dimensions 
for which content advisories are specified for this event. The value of this field shall not be 
greater than the value specified by the field dimensiorisjjefined in the corresponding RRT section. 



Table 6,18 Bit Stream Syntax for the Content Advisory Descriptor 



Syntax 


Bits 


Format 


content_advisory_descnptor () { 






descriptorjag 


8 


0x87 


descriptorjength 


6 


liimsbf 


reserved 


2 




ratsng_region_co«nt 


6 




for (i=0; i<rating_region_coiint; i++) { 






ratmg_region 


8 


uirnsbf 


rated_drmerisions 


8 


uimsbf 


for (j=0;j<rated_dimensions;j++) { 






rating_dimerssionJ 




uirnsbf 


reserved 




'1111' 


rating_vaiue 


4 


uimsbf 


rat!ng_descripiion_!ength 


8 


uimsbf 


rating description text{) 

} 

} 


var 





rating_dimensionj — An 8-bit unsigned integer field specifies the dimension index into the RRT 
instance for the region specified by the field rating_region. These dimension indices shall be listed 
in numerical order, i.e., the value of rating jjimensionj-t-1 shall be greater than that of 
raiing_dimensionJ. 

ratirsg_va!ue — A 4-bit field represents the rating value of the dimension specified by the field 
rating_dimensionJ for the region given by ratirrg_region. 

ratirsg_description_!ength — An 8-bit unsigned integer value in the range zero to 80 that represents 
the length of the ra?mg_descriplionjext{) field to follow. 

rating_descriptiori_text{) — The rating description in the format of a multiple string structure (see 
Section 6.8). The rating_description display string shall be limited to 16 characters or less. The 
rating description text shall represent the program's rating in an abbreviated form suitable for on- 
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screen display. The rating description text collects multidimensional text information into a 
single small text string. If "xxx" and "yyy" are abbreviated forms for rating values in two 
dimensions, then "xxx-yyy" and "xxx (yyy)" are examples of possible strings represented in 
rating_description_text(). 

6.7.5 Extended Channel Name Descriptor 

The extended channel name descriptor provides the long channel name for the virtual 
channel containing this descriptor. 

The bit stream syntax for the extended channel name descriptor is shown in Table 6.19. 



Table 6.19 Bit Stream Syntax for the Extended Channel Name Descriptor 



Syntax 


Bits 


Format 


extended_channe!_name_descriptor () { 






descriptor_tag 


8 


OxAO 


descriptorjength 


8 


uimsbf 


Song channel name text?) 

} 







descriptor_tag — This 8-bit unsigned integer shall have the value OxAO, identifying this descriptor 
as extended j:hannel_narne_descriptor(). 

descriptorjength — This 8-bit unsigned integer specifies the length (in bytes) immediately 
following this field up to the end of this descriptor. 

iong_channei_name_text{) — The long channel name in the format of a multiple string structure 
(see Section 6.8). 

6.7.6 Service Location Descriptor 

This descriptor specifies the stream types, PID and language code for each elementary 
stream. An instance of this descriptor shall appear in the TVCT for each active channel. A 
service_location_descriptor() shall not be present for any inactive channel. When present, the 
servicejocation_descriptor() must be valid for the current event in the corresponding virtual channel. 

Note that for cable, the information in the service_location_descriptor() is carried in the PMT 
with the syntax defined by Ref. [10]. 

The bit stream syntax for the service_location_descriptor() is shown in Table 6.20. 
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Table 6.20 Bit Stream Syntax for the Service Location Descriptor 





Bits 


Format 


service_location_descriptor () { 






descriptor_tag 


8 


0xA1 


descriptorjersgth 


8 


uimsbf 


reserved 


3 


'111' 


PCRJHD 


13 


uimsbf 


number_elements 


8 


uimsbf 


for (i=0;i<number_elements;i++) { 






stream_type 


8 


uimsbf 


reserved 




'111' 


eSementary__PID 


13 


uimsbf 


ISO 639 language code 

} 

} 


8*3 


uimsbf 



descriptorjag — This 8-bit unsigned integer shall have the value OxAl, identifying this descriptor 
as service_location_descriptor(). 

descriptorjength — This 8-bit unsigned Integer specifies the length (in bytes) immediately 
following this field up to the end of this descriptor, 

PCR.PID — This is a 13 bit field indicating the PID of the Transport Stream packets which shall 
contain the PGR fields valid for the program specified by program_number. If no PGR is associated 
with a program definition for private streams then this field shall take the value of OxlFFF, 

number_etemersts — This 8-bit unsigned integer indicates the number of PIDs used for this 
program, 

streamjype — This 8-bit unsigned integer field specifies the type of the elementary stream 
according to Table 6.21 . 



Table 6.21 Stream Type Assignments 



Value 


Description 


0x00 


ITU-T | ISO/iEC Reserved 


0x0i-0x7F 


ofRef. [10] 


0x80 


[Used in other systems] 


0x81 


ATSC A/53 audio 


0x82-0x84 


[Used in other systems] 


0x85 


UPSD (Ref.[5]) 


0x86-0xBF 


Reserved 


QxCO-OxFF 


User Private 



e!ementary_P!D — Packet Identifier for the elementary stream. 

!SO_839_ianguage_code — This 3 -byte (24 bits) field, based on ISO 639.2/B, specifies the 
language used for the elementary stream. In case of no language specified for this elementary 
stream, e.g. video, each byte shall have the value 0x00. 
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6.7.7 Time-Shifted Service Descriptor 

This descriptor links one virtual channel with one or more virtual channels that carry the 
same programming on a time-shifted basis, The typical application is for Near Video On Demand 
(NVOD) services. 

The bit stream syntax for the time_shifted_service_descriptor() is shown in Table 6.22. 



Table 6.22 Bit Stream Syntax for the Time Shifted Service Descriptor 



Syntax 


Bits 


Format 


time_shifted__service_descriptor {) { 






descfiptor_tag 


8 


0xA2 


descriptorjength 


8 


uimsbf 


reserved 


3 


, 11r 


num!jer_of_services 


5 


uimsbf 


for (i=0;i<number_of_services;i++) { 






reserved 


6 


'11111V 


time_shift 


10 


uimsbf 


reserved 


4 


'111V 


major_cfoarjSieLr!iJrnber 


10 


uimsbf 


minor channel number 

} 

} 


10 


uimsbf 



deseriptorjag — This 8-bit unsigned integer shall have the value 0xA2, identifying this descriptor 
as time_shifted_service_descriptor(). 

descriptorjength — This 8-bit unsigned integer specifies the length (in bytes) immediately 
following this field up to the end of this descriptor. 

numbcr_of„services — A 5-bit number in the range 1 to 20 that indicates the number of time- 
shifted services being defined here. 

time_shift — A 3 0-bit number in the range 1 to 720 that represents the number of minutes the 
time-shifted service indicated by major_channel_number and minor_channel_number is time-shifted 
from the virtual channel associated with this descriptor. 

major_charsneLniimber — A 10-bit number in the range 1 to 999 that represents the "major" 
channel number associated with a time-shifted service. 

minor_channel_number — A 10-bit number in the range 0 to 999 that, when non-zero, represents 
the "minor" or "sub-" channel number of the virtual channel that carries a time-shifted service. 

6.7.8 Component Name Descriptor 

Table 6.23 defines the component_nanfie_descriptor{) ) which serves to define an optional 
textual name tag for any component of the service. 
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Table 6,23 Bit Stream Syntax for the Component Name Descriptor 



Syntax 


Bits 


Formal 


component_name_descriptor() { 






descriptorjag 


8 


0xA3 


descriptorjength 


8 


uimsbf 


component rsarr-e strirsg() 

} 







descriptor_tag — This 8-bit unsigned integer shall have the value 0xA3, identifying this descriptor 
as component_narne_descriptor. 

descriptorjersgth — This 8-bit unsigned integer specifies the length (in bytes) immediately 
following this field up to the end of this descriptor. 

comp©nent_narr!e_s!ring{) — The name siring in the format of a multiple string structure (see 
Section 6.8). 

6.7.9 Stuffing Descriptor 

For certain applications it is necessary to define a block of M bytes as a placeholder. The 
N bytes themselves are not to be processed or interpreted. The stutfing_descnptor() is specified for 
this purpose. The stuffing_descriptor() is simply a descriptor type for which the contents, as indicated 
by the descriptorjength field, are to be disregarded. The tag type for the stuffing descriptor is 0x80. 
The stuffirig_descriptor{) may appear where descriptors are allowed in any table defined in the PSIP. 

6.7.10 Descriptors for Inactive Channels 

The service _iocation_descriptor() shall not be present for inactive channels. Any other 
descriptors, if present, shall provide valid information about the inactive channel. The 
extended_channel_name_descriptor(), for example, can be used to provide the long-form channel name 
of the inactive channel. 

6.8 Multiple String Structure 

This is a general data structure used specifically for text strings. Text strings appear as 
event titles, long channel names, the ETT messages, and RRT text items. The bit stream syntax 
for the Multiple String Structure is shown in Table 6.24. 

number_strlngs — This 8-bit unsigned integer field identifies the number of strings in the 
following data. 

!SO_639Jangusge_cGde — This 3 -byte (24 bits) field, in conformance with ISO 639.2/B, specifies 
the language used for the i !h string. 

niiiT3ber_segrTients — This 8-bit unsigned integer field identifies the number of segments in the 
following data. A specific mode is assigned for each segment. 
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Table 6,24 Bit Stream Syntax for the Multiple String Structiire 



Syntax 


Bits 


Format 


multiple_string_structure () { 






mimberjstrings 


8 


uimsbf 


for (i= 0;l< number_strings;i++) { 






iSO_633Janguage_code 


8*3 


uimsbf 


number_segmerits 


8 


uimsbf 


for (j=0;j<number_segmertts;j++) { 






compressionjype 


8 


iiimsbf 


mode 


8 


uimsbf 


number_bytes 


8 


uimsbf 


for (k= 0;k<numberjDytes;k++) 






compressed strirsg byte [k] 

} 

} 

} 


8 


bslbf 



compressionjype — This 8-bit field identifies the compression type for the j in segment Allowed 
values for this field are shown in Table 6.25. 



Table 6.25 Compression Types 



compressionjype 


compression inelhod 


0x00 


No compression 


0x01 


Huffman coding using standard encode/decode 
tables defined in Table C.4 and C.5 in Annex C. 


0x02 


Huffman coding using standard encode/decode 
tables defined in Table C.6 and C.7 in Annex C. 


0x03 to OxAF 


reserved 


OxBO to OxFF 


user private 



mode — An 8-bit value representing the text mode to be used to interpret characters in the 
segment to follow. See Table 6.26 for definition. Mode values in the range zero through 0x3E 
select 8-bit Unicode™ character code pages. Mode value 0x3 F selects 16-bit Unicode™ 
character coding. Mode values 0x40 through OxDF are reserved for future use by ATSC. Mode 
values OxEO through OxFE are user private. Mode value OxFF indicates the text mode is not 
applicable. Decoders shall ignore string bytes associated with unknown or unsupported mode 
values. 

numfaer_bytes — This 8-bit unsigned integer field identifies the number of bytes that follows. 
compressed_stririg_byte[k] — The k th byte of the j lh segment. 
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Table 6.26 Modes 



Mode 


Meaning 


Languagefs) or Script 


0x00 


Select 1 SO/1 EC 10646-1 Page 0x00 


ASCII, ISO Latin4 (Roman} 4 


0x0 1 


Select ISO/IEC 10646-1 Page 0\01 


European Latin (many) 5 


0x02 


Select 1SO/1EC 10646-1 Page 0x02 


Standard Phonetic 


0x03 


Select ISO/IEC 10646-1 Page 0x03 


Greek 


0x04 


Select ISO/IEC 106464 Page 0x04 


Russian, Slavic 


0x05 


Select ISO/IEC 106464 Page 0x05 


Armenian, Hebrew 


0x06 


Select ISO/IEC 10646-1 Page 0x06 


Arabic 6 


0x07-0x08 


Reserved 




0x09 


Select ISO/IEC 10646-1 Page 0x09 


Devanagari 7 , Bengali 


OxOA 


Select ISO/IEC 10646-1 Page OxOA 


Punjabi, Gujarati 


OxOB 


Select ISO/IEC 106464 Page OxOB 


Oriya, Tamil 


OxOC 


Select ISO/IEC 10646-1 Page OxOC 


Teiugu, Kannada 


OxOD 


Select ISO/IEC 10646-1 Page OxOD 


Malayalam 


OxOE 


Select ISO/IEC 10646-1 Page OxOE 


Thai, Lao 


OxOF 


Select ISO/IEC 10646-1 Page OxOF 


Tibet?". 


OxiO 


Select ISO/IEC 10646-1 Page 0x10 


Georgian 


0x11 -Ox IF 


Reserved 




0x20 


Select ISO/IEC 106464 Page 0x20 


Miscellaneous 


0x21 


Select ISO/IEC 10646-1 Page 0x2! 


Misc. symbols, arrows 


0x22 


Select ISO/IEC 10646-1 Page 0x22 


Mathematical operators 


0x23 


Select ISO/IEC 10646-1 Page 0x23 


Misc. technical 


0x24 


Select 1 SO/I EC 10646-1 Page 0x24 


OCR, enclosed aipha-num. 


0x25 


Select ISO/IEC 10646-1 Page 0x25 


Form and chart components 


0x26 


Select ISO/IEC 10646-1 Page 0x26 


Miscellaneous dingbats 


0x27 


Select ISO/IEC 10646-1 Page 0x27 


Zapf dingbats 


0x28-0x2F 


Reserved 




0x30 


Select ISO/IEC 10646-1 Page 0x30 


Hiragana, Katakana 


0x31 


Select ISO/IEC 10646-1 Page 0x31 


Bopomopho, Hangul elem. 


0x32 


Select ISO/IEC 10646-1 Page 0x32 


Enclosed CJK Letters, ideo. 


0x33 


Select ISO/IEC 10646-1 Page 0x33 


Enclosed CJK Letters, ideo. 


0x34-0\31 


Reserved 




0x3 r- 


Select 1 6-bit ISO/IEC 10646-1 mode 


'"ail 


Ux40-0kDF 


Reserved 




OxEO-OxFr- 


LV; pn\ ate 




o-j-r 


Not applicable 





7. PSIP STD MODEL 

7, 1 Buffer Mode/ for Terrestrial Broadcast 

4 The languages supported by ASCII plus the Latin-i supplement include Danish, Dutch, English, Faroese, Finnish, 
Flemish, German, Icelandic, Irish, Italian, Norwegian, Portuguese, Spanish and Swedish. Many other languages can 
be written with this set of characters, including Hawaiian, Indonesian, and Swahili. 

5 When combined with page zero (ASCII and ISO Latin-!), covers Afrikaans, Breton, Basque, Catalan, Croatian, 
Czech, Esperanto, Estonian, French , Frisian, Greenlandic, Hungarian, Latin, Latvian, Lithuanian, Maltese, Polish, 
Provencal, Rhaeto-Romanic, Romanian, Romany, Sami, Slovak, Slovenian, Serbian, Turkish, Welsh, and many 
others. 

b Also Persian, Urdu, Pashto, Sindhi, and Kurdish. 

Devanagari script is used for writing Sanskrit and Hindi, as well as other languages of northern India (such as 
Marathi) and of Nepal (Nepali). In addition, at least two dozen other Indian languages use Devanagari script. 
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Table 7.1 lists the maximum cycle time for all PSIP tables, except EITs and ETTs, Table 
7.2 lists the maximum transmission rate for PSIP packet streams according to their PIDs. The 
recommended maximum cycle time for Elf -0 is 500 ms. 



Table 7.1 Maximum Cycle Time for the STT, MGT, VCT and RRT 



Tabk 


STT 


MGT 1 VCT 


RRT 


Cycle time (ms) 


1000 


150 1 400 


60000 



Table 1,2 Maximum Rate for Each PSIP Packet Stream 



PID 


base_PlD j EITJPID 


ETT PID 


Rate (bps) 


250.000 i 250.000 


250,000 



For terrestrial broadcast applications the following constraints apply: 

® In terrestrial broadcast applications, the PSIP elementary streams identified by- 
Transport Stream packets with PID OxlFFB (base_PiD), ElT PIDs and ETT PIDs shall 
adhere to an STD model with the following parameters: 

» sbjeakjaie shall be 625 (indicating a leak rate of 250,000 bps) 

® sb_size shall be 1 024 (indicating a smoothing buffer size of 1 024 bytes) 

7.2 Buffer Mode/ for Cable 

Transmission rates for cable will be standardized by the SCTE. 
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Annex A 

(Normative) 

Daylight Savings Time Control 

In order to convert GPS into iocai time, the receiver needs to store a time offset (from 
GPS to local time) in local memory and an indicator as to whether daylight sayings is observed. 
These two quantities can be obtained from the user interface (indicating time zone and daylight 
savings observance) or from the conditional access system, if present, and stored in non-volatile 
receiver memory. 

Since there is a common time (GPS) transmitted in the PS3P, there needs to be a 
mechanism to indicate when the receiver should switch into (or out of) daylight savings time at 
the appropriate local time. Once all the receivers have transitioned at their local times, the entire 
system can be shifted into daylight savings time. This is accomplished by appropriate setting of 
the daylight_savings in the STT. The structure of daylight savings time control is shown in Table 
A.l, and the basic use of daylight savings fields through the year is shown in Table A.2. 



Table A.l Structure of Daylight Savings Time Control 



Syntax 


Bits 


Format 


day[ight_savings () { 






DS_status 


1 


bslbf 


reserved 


2 




DS_day_of_morsth 


5 


uimsbf 


DS hour 

} 


8 


uimsfaf 



DS_status — This bit indicate the status of daylight savings. 

DS_status = '0': Not in daylight savings time. 

DS_status = ' P: In daylight savings time. 

DS_day_of_month — This 5-bit unsigned integer field indicates the local day of the month on 
which the transition into or out of daylight savings time is to occur (1-31). 

DS_hour ■ — This 8-bit unsigned integer field indicates the local hour at which the transition into 
or out of daylight savings time is to occur (0-18). This usually occurs at 2 a.m. in the U.S. 
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Table A.2 Basic Use of Daylight Savings Fields Through the Year 







of month 


OS hour 

5 


At the beginning of the year (January) daylight savings is off'. This 
is the status of the fields until: 


0 


0 


« When the transition into daylight savings time is within less 
than one month, the DS_day_of_month field takes the value 
day_in, and the DS_hour field takes the value hourjn. The 
DS_s*ati.iS bit is 0 indicating it is not yet daylight savings 
time. (The transition is to occur on the day_in day of the 
month at hour=hour_in; for example, if the transition were on 
April 15 at 2 a.m., then day_in=15 and hourJn=2) 


0 






• After all time zone daylight transitions (within the span of the 
network) have occurred, the DS_status bit takes the value 1, 
indicating that daylight savings time is on. The 
DS_day_of_month field and the DSJiour field take the value 
0. (in the U.S., this transition has to occur no later than 7 p.m. 
Pacific Time on the day dayjn). 

This is the status of the fields until: 


1 


« 


0 


When the transition out of daylight savings time is within less than 
one month, the DS_day_of_month field takes the value 
day_out, and the DS_hour field takes the value hour_out. The 

(The transition is to occur on the day_out day of the month at 
hour=hour_out; for example, If the transition were on October 
27 at 2 a.m., then day_out=27 and hour_out=2) 


\ 


day_out 


hour_out 


* After all time zones (within the span of the network) have 
shifted out of daylight savings time, the DS„status bit takes 
the value 0, indicating that daylight savings time is off. The 
DS_day_of_month field and the DS_hour field take the value 
0. (fn the U.S., this transition has to occur no later than 7 p.m. 
Pacific Time on the day day_out). 

This finishes the cycle. 


0 


0 
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Annex B 

(Normative) 

Assignment of IVIajor Channel Number Values For 
Terrestrial Broadcast in the U.S. 

The assignment of major_channel_number values in the U.S. is based on the rules below. 

* For broadcasters with existing NTSC licenses, the major_channel_number for the existing 
NTSC channels, as well as the Digital TV channels, controlled by the broadcaster, 
shall be set to the current NTSC RF channel number. E.g. Assume a broadcaster who 
has an NTSC broadcast license for RF channel 13 is assigned RF channel 39 for 
Digital ATSC broadcast, That broadcaster will use major_channel_number 13 for 
identification of the analog NTSC channel on RF channel 13, as well as the digital 
channels it is controlling on RF channel 39. 

* For a new broadcaster without an existing NTSC license, the major_channel_number for 
the Digital TV channels controlled by the broadcaster shall be set to the FCC assigned 
RF channel number for ATSC Digital TV broadcast. E.g. Assume a broadcaster who 
currently has no NTSC broadcast license applies and receives a license for Digital 
ATSC broadcast on RF channel 49. That broadcaster will use major_channel_number 49 
for identification of the digital channels that it is controlling on RF channel 49. 

* The two provisions above assign major_channel_number values 2 through 69 uniquely to 
broadcasters with license to broadcast NTSC and/or Digital ATSC signals. 

» Values for major_channe!_number from 70 to 99 may be used to identify groups of digital 
services carried in an ATSC multiplex that the broadcaster wishes to be identified by 
a different major channel number. Values 70 through 99 must be unique in each 
potential receiving location or the receiver will not be able to correctly select such 
services. For example a local broadcaster transmitting community college lectures in 
its bit stream may want to use a major_channel_number different than lis own 
major_channel_nurriber for the virtual channel carrying the lectures. The assessment of 
the feasibility of using this capability, as well as the coordination process for 
assignment of these major_channel_number values is beyond the scope of this document. 
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Annex C 

(Normative) 

Standard Huffman Tables for Text Compression 8 

This Annex describes the compression method adopted for the transmission of English- 
language text strings in PSIP. The method distinguishes two types of text strings: titles and 
program descriptions. For each of these types, Huffman tables are defined based on Ist-order 
conditional probabilities. Section C.2 defines standard Huffman encode and decode tables 
optimized for English-language text such as that typically found in program titles. Section C.3 
defines Huffman encode and decode tables optimized for English-language text such as that 
typically found in program descriptions. Receivers supporting the English language are expected 
to support decoding of text using either of these two standard Huffman compression tables. 

The encode tables provide necessary and sufficient information to build the Huffman 
trees that need to be implemented for decoding. The decode tables described in Tables C.5 and 
C.7 are a particular mapping of those trees into a numerical array suitable for storage. This array 
can be easily implemented and used with the decoding algorithm. However, the user is free to 
design its own decoding tables as long as they follow the Huffman trees and rides defined in this 
Annex. 

C1 . CHARACTER SET DEFINITION 

This compression method supports the full ISO/TEC 8859- 1 (Latin- 1) character set, 
although only characters in the ASCII range (character codes I to 1 27) can be compressed. The 
following characters have special definitions: 



Table C.l Characters with Special Definitions 



Character 


Value 
(Decimal) 


Meaning 


Siring Terminate 
(ASCII Null) 


0 


The Terminate character is used to terminate strings. The 
Terminate character is appended to the string in either 
compressed or uncompressed form. 
The first encoded character in a compressed string is 
encoded/decoded from the Terminate sub-tree. In other words, 
when encoding or decoding the first character in a compressed 
string, assume that the previous character was a Terminate 


Order- i Escape 
(ASCII ESC) 


27 


Used to escape from first-order context to uncompressed 
context. The character which follows the Escape character is 
uncompressed. 



8 Tabies C.4 through C.7 are © 3997 General instrumcn- Corpc-ation Unlimited use m conju ict or w th this ATSC 
standard is granted on a royalty-free basis by General Instrument Corporation. Ail other rights are reserved. 
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C1.1 First Order Escape 

The order- ! Huffman trees are partial, that is, codes are not defined for every possibfe 
character sequence. For example, the standard decode tables do not contain codes for the 
character sequence qp. When uncompressed text contains a character sequence which is not 
defined in the decode table, the order- 1 escape character is used to escape back to the 
uncompressed context. Uncompressed symbols are coded as 8-bit ASCII (Latin I). For example, 
the character sequence qpa would be coded with compressed q, compressed ESC, uncompressed 
p, compressed a. 

First-order escape rules for compressed strings; 

• Any character which follows a first-order escape character is an uncompressed (8-bit) 
character. (Any character which follows an uncompressed escape character is 
compressed). 

« Characters (1 28 .. 255) cannot be compressed. 

» Any character which follows a character from the set (128 .. 255) is uncompressed. 

C1.2 Decode Table Data Structures 

Decode tables have two sections: 

• Tree Root Offset List: Provides the table offsets, in bytes from the start of the decode 
table, for the roots of the 1 28 first-order decode trees. The list is contained in bytes (0 ,. 
255) of the decode table, and Is defined by the first "for" loop in Table C.l . 

• Order- 1 Decode Trees: Each and every character in the range (0 .. 127) has a 
corresponding first-order decode tree. For example, if the previous character was "s", then 
the decoder would use the "s" first-order decode tree (decode tree #1 15) to decode the 
next character (ASCII "s" equals 115 decimal). These 128 decode trees are delimited by 
the second "for" loop in Table C.2. 

Decode tables have the following format: 



Table C.2 Decode Table Format 



Syntax 


Bits 


Format 


decode_table() { 






for (i==0; i<128; { 






byte offset of char i tree root 


16 


uimsbf 


} 

for (i==0; i<128; i++) { 






character i order 1 tree{) 

} 


8*M 





Note that even though the ISO Latin- 1 character set supports up to 256 characters, only 
the first 128 characters may be represented in compressed form. 



ATSC 



Rev. A to PS IP for Terrestrial Broadcast and Cable (A/65) 



5/31/00 



C1. 2.1 Tree Root Byte Offsets 

byte_offset_of_character_ijree_root — A 1 6-bit unsigned integer specifying the location, in bytes 
from the beginning of the decode table, of the root for the i il! character's order-i tree. 

C1.2.20rdeM Decode Trees 

Order-l decode trees are binary trees. The roots of the decode trees are located at the table 
offsets specified in the tree root offset list. The left and right children of a given node are 
specified as word offsets from the root of the tree (a word is equivalent to two bytes). 

Decode trees have the following format: 



Table C.3 Decode Tree Format 



Syntax 


Bits Format 


character_i_order_1_tree() { 




for(j==0;j<N;j++){ 




left child word offset or char feaf 


8 uirosbf 


right chi!d word offset or char leaf 

} 

} 


8 uimsbf 



ieft_ch!id_word_offset_or_charjeaf — An 8-bit unsigned integer number with the following 
interpretation: If the highest bit is cleared (i.e. bit 7 is zero), the number specifies the offset, in 
words, of the left child from the root of the order-l decode tree; if the highest bit is set (bit 7 is 
one), the lower 7 bits give the code (e.g., in ASCII) for a leaf character. 

right_ehHd_word_offset„or_charjeaf — An 8-bit unsigned integer number with the following 
interpretation: If the highest bit is cleared (i.e. bit 7 is zero), the number specifies the offset, in 
words, of the right child from the root of the order-l decode tree; if the highest bit is set (bit 7 is 
one), the lower 7 bits give the code (e.g., in ASCII) for a leaf character. 

It can be seen from Figure F.3 that each node (corresponding to one iteration of the for- 
loop) has a byte for the left child or character, and a byte for the right child or character. 

Characters are leaves of the order-i decode trees, and are differentiated from intermediate 
nodes by the byte's most significant bit. When the most significant bit is set, the byte is a 
character leaf. When the most significant bit is not set, the byte contains the tabular word offset 
of the child node. 
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C2. STANDARD COMPRESSION TYPE 1 ENCODE/DECODE TABLES 

The following encode/decode tables are optimized for English-language program title 
text. These tables correspond to multiple_string_structure() with compression jype value 0x0 1, and a 
mode equal to OxFF. 



1 if le C 4 English-language Program Title Encode Table 



Poor svmboi: t 
Pnorsvmbol: i 1 



: 15 Symbol: 2? Code: 1 

. 16 Symboi: 27 Code: 1 

2 C 

m 2 C e 



Prior Symbol: 
Prior Symbol: 

Prior Symbol: 

Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol. 



>rior Symbol: 
>rior Symbol: 



Symbol:'-' Code: 00000001 
Symbol:"i' Code: 01000010 
Symbol:? Code: 00000010 
Symbol:'? Code: 01000001 
Symbol: '9' Code: 00000000 
Symbol: 'A' Cods: 10111 
Symbol: 'B' Code: 0010 
Symbol: 'C Code: 1100 
Symbol: V Code: 1 HOG 
Symbol: 'E' Code: 011010 
Symbol: 'F' Code: 10011 
Symbol: 'G' Code: 00001 
Symbol: "rl' Code: 10101 
Symbol:'!' Code: 111111 
Symbol: 'J' Code: 
Symbol: 'K' Code: 




" Symbol: 'W Code: 0011 

" Symbol: 'X' Code: 0000000010 

" Symbol: X Code: 00000011 

" Symbol: 'a' Code; 01100 

' ' Symbol: 'b' Code: 10010101 

' ' Symbol: X Code: 01000000 

' ' Symbol: 'e' Code: O 

' ' Symbol: T Code: 1C 

' ' Symbol: T Code: 01 

' ' Symbol: T Code: 10 

" Symbol: T Code: 01 



Prior Symbol: - 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior S' ~ 

Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 



%' Symbol: 27 Code: 1 
6' Symbol: 27 Code: 0 
X: '&' Symbol: ' ' Code: 1 

Symbol. " Code: 010 
"' Symbol: '& Code: 0001 
~ Symbol: 'd' Code. 0000 
'" Symbol: 's' Code. ! 
"' Symbol: T Code: 00! 
'f Symbol: 27 Code: 1 
T Symbol- 27 Code: 1 
-' Symbol: 27 Code: 00 

- Symbol: 'H' Code: 10 

- Symbol: 'S' Code: 1 1 




Cede '< 



lor Symbol; 
lor Symbol: 

lor Symbol: '-' Symbol; 'U' 
iot Symbol " Symbol g 
W Symbol: '.' Symbol; 2? 
iot Symbol ' 1 Symbol- ■ code 
ior Symbol " Symbol • cole 
iot Symbol " Sysibcl 1 Code 
ior Symbol " Syfiibo' 'S' Cods 
lor Symbol " Symbol- W Co* 
ior Symbol; r Symbol: 2? Codi 



Pnor Symbol '<S Syrftbtf, ' ' Code ft 



Prior Syinbo' V 

Prior Symbol; T 
Prior Symbol: T 

Pnor Symbol T 

Pnor Symbol 'i 

Pnor Symboi: * 
Pnor Symbol: y T 
Pnor Symbol: t 

Pnor SyJTfbo!: " 

Pnor Symbol: 'f 
Pnor Symbol" 
Pnor Symbol; '; 
Pnor Symbol: 'i 
Pnor Symbol: "'< 
Pnor Symboi;'! 

Prior Symbol: 1 
Prior Symbol: 1 



Symbol; V Code: « 
Symbol; 0 Cede: 010 
Symtoi; 27 CocteOJI 
Syn srji ' ' Code ifl 
Symbol 'S Code 111 
SymW T Code 100 
Symbol ? Code 101 
Syifbo" ■S* '3oae 00 
Symboi 0 Ceae H 
Symbol; 27 Co*: 10 



Syrabsfff Co*: 10 
Symbol; 27 Cafe: 0 
Symoal- '8' Cods 1 



Prior Symbol: 
Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 

Pnor Symbol: 
Pnor Symboi: 
Prior Symbol: 
Pnor Symbol: 



t Symbol •¥ Cod© 101 
/ Symbol -9' Code 00 
■ Syrftboi 27 Coa<? 0 
:' Symbol: ■ ' Cooe: t 



■ Symbol 27 Cooe i 
Symbol 27 Ccce 1 

■ Symbol 27 Coos 1 
' Symbol: 0 Goes: 3 
' Symbol: 2? CcKfeQ 

•© bvmboi 27 Cooe ■ 
Symbol, 27 Co* 00 
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no °fnbol A Syrrrxl t de b 
Prior Symbol: A' Symbol:'.' Code: 1101! 
Poor Symbe*. A' Symbol: 'B' Code: 1 1 01 
no mb Syrrbol Cod X 
no y-nte Syrrbol c ("ode 0 o 
r'nor symbol: A' Symbol: d' Code: Qui 
hro symboi: A' Symbol: T cooe: 0110' 
r'nor symbol: A' Symbol: g Code: 0il1 
r'nor symbol: A' Symbol: T wide: 11Q0' 1 



Prior Symi 
Prior Symi 
Prior Symi 



•J Symbol: 27 Code: 00101 
Symbol: 'A' Code: 0011100 



j' Symbol: i 



fod 11 
V Code: 01 



E "Vrntx. rode ii " 

J I c yTlbO <"jdt( ' 11 

F Syibi te <0 

I F ^yp bt Code 3 0 



c "i5o F /mbo! 



c >iri> rod 



Symbol: 'G' Symbol: '3' Code: 1110 
Symbol: G' Symbol: e Code: 1i0 
Symbol: 'G' Symbol: 'h' Code: 10100 
Symbol: G' Symbol: T Coda: 100 
Symbol: 'G' Symbol:'!' Coda: 101011 
G' Symbol: 'o' Code: 01 



Pnor symbol: 
Pnor symbol: 
Pnor symbol: 
Pnor symbol: 
Pnor symbol: 
Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 

Pnor Symbol: 
Pnor Symbol: 



+ Symbol: il Code: mull 
•I' Symbol: 'a' Code: 110 
•f Symbol: 'e' Code: 10 
-I' Symbol:'!' Code: 1111 
-f Symbol: 'o' Code: 0 

i Symbol: 0 Code: 1000 
i' Symboi: 2? Code: 100! 
r symboi:" Code: 111i0 
Synbo Code < 1 4 0 
: Symbol: : 1 Code: 101 110 
,■ Symoort Code: liOO 
:■ Symooi: T Code: 101 ill 

! Symooi: m code: 1010 



T Symooi: t Cor 
J' Symbol: 27 C 



Pnor Symbol: T 
Pnor symbol: J' 
Prior Symboi: 'J' 
Prior Symb " 
Pnor Symboi: J' 
Pnor symboi: J' 
Pnor Symooi: K 
Prtor Symboi: : K' Symbol"* Code: 01 
Pic Symooi K S,rrb-I e Code 0i 
Prior Symboi: 'K Symbol: '? Code: 1 
p„or ?vi ibv K Symbol i Code 0 
Prior Symboi: K' Symbol: 'C Code: 01 
Pnor symooi: K' Symbol: v Code: 01 
Pnor Symbol: t Symboi: 27 Code: 0 
Pyx Sy no" L oymbo 1 Lode 0 ( 



Pnor Symooi: 1' 



*1f Symbol: '!' Code: 10111' 



Pi.oi oc! 

P™ ^' 



Fno/Syrrbst N Vol 



lor Symbol: 
ior Symbol: 



y Symbol: ' Code: 001 
j Symbol: 'd' Code: 011 
7 Symbol: T Cods: 110' 
7 Symbol:'!' Code: 11 0( 
j Symbot'n' Code: 10 
3' Symbol: '«' Code: 000 
3 Symbol; r Code: Oni 
j Symbol's' Code: 011 
" Symbol . Code 111 



Prior Symbol: 

Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 



Prior Symbol; 
Prior Symboi: 
Prior Symboi: 
Prior Symbol: 
Prior Symbol: 
Prior Symboi: 
Prior Symboi: 
Prior Symbol: 
Prior Symbol: 



'O' Symbol: V Code; 11011 
'O' Symbol: W Code: 0000 
:'P Symbol. 27 Code: 111111 
:'P' Symbol:" Code: 1111100 
:'F Symbol: V Code: 011001 
'P Symbol: 'G' Cods: 111101 

V Symbol: 'R' Code: 111100 
'P Symbol; 'a Code; OS 
'P Symbol: V Code; 010 

■P' SymbotT Code: 1110 

V Symbol: 'o' Code: 110 
'P Symbol. '{ Code: 10 

'P' Symbol: 'u Code: 01101 
'P' Symbol: y Code: 011000 

V Symboi: 27 Code: 00 
'Q' Symbol: V Code: 01 
'Q' Symbol: V Code: 1 

'R' Symboi: 27 Code: 10001 

•R' Symbol's' Coda 11 
•R' Symboi; '!' Code. 00 

'S' Symbol: 27 Code: 101110 
'S' Symbol;" Code: 1110100 
■S' Symbol:'*' Code: 1011000 
■S' Symbol:'.' Code: 1011011 
'S' Symboi: 'a' 



1100 

'S' Symboi: 'e' Code: 000 
'S' Symboi: 'ft' Cods. 100 
'S' Symbol:'!' Code: 1100 




Prior Symboi: 
Prior Symboi: 

ior Symboi: 
ior Symboi: 
Prior Symboi: 

Prior Symboi: ' 



V Symbol: 'e' Code: 0100 

V Symbol: V Code: 1 

V Symboi: '0' Code: 0010 
W Symboi: 27 Code:00Q11 
'W Symbol: V Code: 000100 
W Symboi; 'W Code: 00010' 
W Symbol's' Code: 111 
W Symbol: 'e' Code: 110 
'VV Symbol: 'h' Code: 001 



f Symbol: "i 



Code; 01 
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ior Symbol: ']' 



P-orSynoo c 
Pnor Symooi: a 
Pnor Symbol: a 



Pr.oi Symo«. d Svmooi: V 

Pnor symboi: e Symboi: 
Pnor symbol: e Symboi: t 
Frors/r*oi e svrnbo 

Pnor symbol: 'e' swrrbo!: ':' 

Pnor symbol: 'e' symbol: t 
Pnor symbol: '0' symbol: i 
Pnor symbol: e' symbol: 'o 



ior Symbol: 1 
or Symbol: T 
lot Symbol: T 
ior Symbol: t 
ior Symbol: t 



ior Symbol: r 
ior Symbol; t 
ior Symbol 



t> S>rrbci b 
* Syirb-i e 
U Syirccll 



Prior symbol » 
PnorS/mtso! » 
Pnor b/rrW s 
Pn<jrS/rf6of » 
Pnor Syffiboti'ff 
Pnor Symbol: T 
fno Synbol f 



Prior Svrnbol: ) 
Pt Svibo J 
Pnor Symboi: k 



Pnor Svmboi: k 
Pnor Symboi: k 
Pi" Sy"l*v k 



Symbol: y Code: 00118 
symbol: 0 Code: 1000 

2? Code: 0111001 



c Syrpoal I Code 00* 



Prior Symbol: 
Prior Symbol: 
Prior Symbol: 

Pnor Symbol: 
Prior Symbol: 

Prior Symbol: 
Prior Symbol: 
Prior Symbol: 



Symbol; 2? Cod* 1110000 
;' Symbol: ' ' Code: 01 
I' Symbol:" Code: 1001100 
{ Symbol:':' Co6e: 11100010 
)• Symbol: 'a' Code: 1000 

)• Symbol: V Code; 00 
f Symbol: ? Code: 11101 

f Symbol: '!' Code: 1111011 

I' Symbol: 'n' Code. 100111 

I' Symbol: '0' Code: 111001 

i Symbol; ? Code: 10018 

!' Symbol: 's' Code: 11111 

I' Symbol: f Code: 1001 101 

!' Symbol: V Code. 111100 

i Symbol: y Code; 11100011 

y Symbol; 0 Code: 11101 

v Symbol; 27 Code: 1110001 

r Symbol:" Code: 1011 
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Prior symbol: itv symi 



Prior Symbol: 
Prior Symbol: 
Pnor Symbol 
Prior Symbol: 
Prior Symbol 
Pno? Symbol; 
Prior Symbol 



•p' Symbol: t Code: 10110 

K Symbol: 27 Code: 0 
'«f Symbol: u' Cook 1 

'f Symsof: 2? Code: 01 100101 

Y Symoot;" Code: 1111 

Y Symbol " C0S8 01100H 

* r Symosii ',' Gods: 1 1 001 1 1 01 
*Y symortv cote: 0111100 

ofc V Symbol: V Code: 1 1 001 1 1 00 
ot: "f Symbol: 'a' Code: 000 
ot Y Symbol; V Cose; 01111101 

* r Symbol: V Code; 0111111 
*r Symbol: If Cook 11000 
*v Symbol. 'e' Cose: 101 
otr Syraboi-.T Code: 11001111 
ol: r Sywbofc 'f Cose: 01 11101 
otv Symbol: Y Co*: 010 

ol v Symbol -k' Code 110010 
oi v Sywboi 1 Code 0OH 
off SytBWm' Code: 011000 
<*V Symbol: W Co*: 0)101 



V Symbol's' Code: 11 
T SymetfV Code: 01 



.1100 



Pnor Symbol: f symbol: u 
Pnor Symbol: t symbol: w 1 
Pnor Symbol: t Symbol: V 
Pnor Symbol: u' Symbol: ( 
Pnor Symbol: v Symbol: 2 
Pnor Symbol.' v Symbol: ' ' 
Pnor Symbol: 'ir Symbol: 'a' 



r Symbol: T Gflde; 1000 



nnvSv-voi u 
P"irSvmsX> u 
Prior Symbol: 'u 
Prior Symbol: v 
Prior Symbol: V 
Prior Symbol: V 
P"crSjmbo v" 



Symbol: 'C Code: 11100 
Svmbol: 'd' Code: 10000 
Symbol: '8' Code: 0010 



Symbol: 'a' 



Pnor Symbol: s 
no s -* c 



PnofSyifto V Symbol y Co* 0610 
Prior Symbol: 's' Symbol: 0 Cods: IT 
Pnor Symbol ' S ' J7 Code 001( 

Pnor Symbol 's' Symbol ' ' Cods 01 
Prior Symbol 's' Symbol * Code 0C 



Pnor Symbol: 's' 



s' Symbol " Cods 00191101 
s' Symbol: '.' Coos: 00100101 



s' Symbol: 'c' Code: 101O1 
s' Symbol: V Code: 00101 
s' Symbol' «' Code iOH 
*• Symbol- T Code- 00000 



s' Symbol: V Code: 000001 
'8' Symbol: T Cods: 00101010 
s' Symbol: m' Code: 00000001 

s' Symbol: o' Code: 10100 
■8' Symbol: 'o' Code; 001000 
s' Symbol: f Code: 00100100 



t Symbol: 0 Code: 010 
t Symbol: 27 Code: 11000010 
f Symbol: ' ' Coae: 10i 
T Symbol:" Code: 11000011 
t Symbol;':- Code: 110110000 
T Symbol: T Code: 110110001 
t Symbol- 'a' Code: 0000 
'!■ Symbol: V Code; 100000 
t Symbol: 'C Code: 1101101 



Prior Symbol: V 
Poor Symbol; » 
Prior Symbol: 'v 
Poor Symbol: '•< 
Pnor Symbol: v 
Pnor Symbol: v 
Pnor Symbol; * 
Prior Symbol'* 
Pnor Symbol; '* 
Prior Symbol; x 
Pnor Symbol: n 
Pnor Symbol; s 
Pnor Symbol: •» 
Pnor Symbol: > 
Pnor Symbol: > 

Poor Symbol: 
Pnor Symbol: 



W Symbol: 2? Code: 01010 

w Syrtv, Cove 0100 C 
w byrA, a Cone 000 



tor Syria* . 

Pnor Symbol: > 
Pnor Symbol: j 
Pnor Symbol: j 
Pnor Symta i 

Pnor Sy-noo' 
Pno ay-nto 1 
Pno Sy-fiboi 
Pno Syfibot 



S/nbcl 1 Code 010110 
Softool 1» Coop "0 
fyrbo! 0 Cods- 01 



/ Sy^oo f C 

/ Syf bet ' C 
i Syfl-bcf 0 t 
/ Syrrfyi V 



*■ S/mfeoi "d Coste 4 030^0 
f 8/fffios 'e Code "0C1 
■s 5/m6oi < code 11:0001 
<r S/rnbof utfe imit 
v Sprite <i C«oe ! 0 '11 
v Synbo 1 Code 11.0010 
y Syntol Code 11-0011 
y Sy»f»l x Code ,s01j00 
> Synbo! ; C«te 1 0 
y Symbol 1 UxJe WW 
y* Symte * Cuds. 1 g'.Oi, 
\ iypnte «• Co** ♦moo 
I 3sw)t» ! 0 f«te 11" 
X Sy nbo ^7 Code 100 
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Table C.5 English-language Program Title Decode Table 



273 214 

274 6 

275 207 



390 227 

391 179 

392 3 



61 116 
63 113 
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653 194 

664 207 

665 223 



974 2!4 
375 2 
976 245 



843 249 

844 233 

845 5 



1063 3 

1064 250 

1065 232 



10S5 227 
1086 249 
108? 12 



1120 236 
1122 243 
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1428 227 

1429 247 

1430 242 



1477 2 

1478 22S 

1479 237 
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1692 167 
1883 172 
1834 191 



1832 225 

1833 2 

1834 3 



1302 228 

1303 240 

1304 237 
1805 225 



1844 155 

1845 2 

1846 3 



1897 6 

1898 247 

1900 155 
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C3. STANDARD COMPRESSION TYPE 2 HUFFMAN ENCODE/DECODE TABLES 

The following encode/decode tables are optimized for English-language program 
description text. These tables correspond to multiple_string_structure() with compressionjype value 
0x02, and mode equal to OxFF. 



Table C.6 Engl Nh-ianguage P ogra De^ription Encode Table 



prior Symbol: 
Prtor Symbol: 
Pnor Symbol: 


0 Symbol: '" Code: 111081 
0 symbol: A' Code: 010 


? r 


iff I C e 10 0000 X 
yn- 1 4, Coo 1 11 
"yrrrx B M 1 100 


Pnor symbol: 
Pnor Symboi: 




27 Code:1 
27 Code:1 


Pnor Symbol: 
Prior Symbol: 


0 Symbol: '8' Code: 0011 
0 Symbol: 'C Cods: 0111 
0 Symbol; Q Code: m01 




w*1> C"vP 11113 5 
yiMf 10001 


P !Syu»o> 
F syi \! 


■ Symbol: 


27 Code:1 

27 Code:1 


Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 


0 Symbol; f Cms: 1u1 10 
0 Symbol: if code: 10111 


Pi y-n 


y«*ot Code * 1 


Pr rS)pr>! 
P rV*l 
Pnor Symbol: 






Prior Symbol: 






ytPM I uxte 1 1 
e ,nNJ C<M 1 X 






)■ Code; 0010 


Prior Symbol: 
Prior Symbol: 

Prior Symbol: 
Poor Symbol: 


0 Symbol: 'J' Code .1100 
0 Symbol: X Code: 00101 
0 Svmbol:'L' Code: 10011 
0 Symbol: W Code: 1111 

0 Symbol: 'O' Code; 01 1001 


P ^ y fx, 
P Sy N 


'(itM X e 0 1 0 
SiN/t W 1 1011 

Syil<VrT " a C 1 00 

'(HUD C«de 01" « 1 


P"a " Puol 


Sylr^ 




Pnor Symbol: 

Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 


0 Symbol: ft Code: 1000 
0 Symbol: P S' Code: 1010 

0 Symbol: V Code: 1110001 
0 Symbol: W code: 011010 


p S ^ °" 


c yi »Oi P* jOo-CIIO 

c yrfM o« 01001 
c yn\l T r i 110 
SymOvS U* " t 11 0 
c )l*td jOc 111H 1 
VW v r"ode " "<> 


Pnor symbol: 

Prior Symbol: 
Pnor symbol: 
Prior Symbol: 




rod? f 1 f 
' Code: 00110 


Prior Symbol: 


t oynbol t> vOie 1 




>r*oi 1 1111 ) 
»rrM for> 1 t Ui0Q01 


p"LS 




S' Code: 00111 


Prtor Symbol: 
Pnor Symbol: 


3 Symbol 27 Cods: 1 

4 SyfrifcOI. 27 Code: 1 


p *™ 


Symbol: 'a' Code: 011 


Pnor symbol. 


f" Symbol 


27 Code: 100 


"r»r Symbol 


5 Symbol: 27 Cods: 1 


Pror y" 


nb"l c " 1X 
Symbol: 'd' Code: 10000 


Prior Symbol; 
rioi c ynbol 




7 ( ode '0 


-no syrtwl 
Pno svnboi 
Pno Sy* 1 *" 1 
frto Sy-nrjor 
•'no jyntel 


ffSy«)Wr27 Code:1 

9 Symbol: 21 Code: 1 

10 Symbol: 27 Code: 1 
" *w*r ? i"ode i 
12 Symbol: 27 Code. 1 

5 Syrrbu a God" 


nc m 
Pro r" « 

p rD C: 


Symbol: 'a' Code: 100011 
Symbol: 'h' Code: 0001 

symbol: r code: nuulili 

ymbo C e 11 


PnorSnbel 
Prior Symbol: 
Prior Symbol: 

Prior Symbol: 
Pnor symbol: 


0 ^rrb-l ! 'jo- 110 
">rrbcl i 7 HI 

Syrrb-I s C de 1 0 
V Symbol: '9' Code: 0 

1 trrtyl a " - 101 
Z Symbol." Code: 11 


^-fC'Sv-aco 
ffio Synrxs' 

Pry Sy i"o 


18 .Symbol: 27 Code: 1 
1? Syffibsi; 27 Code: 1 
18 Symbol: 2? Code: 1 

20 Symbol: 2? Code: 1 

21 Syrtbot 2? Code: 1 

22 .Syrobet: 27 code: 1 


Pp\ py, 


y U Co4 M 


Pnor symbol: 


? Symbol: 
3' Symbol: 

ymbol 
4 symbol: 


node - " 
V "0 10 

0 


P"Of i/Mha 


24 Symbol: 27 Code: 1 

25 Symbol: 2/ uxte: 1 








y-nbol 


' Code: 10 


P"vr& mK> 


2s symbol: V code: 1 
28 Symbol; 27 Code. 1 


Pror^ym 


y-rbo r t 0 
Symbol: 2? Ccce: 1 

' Symbol: 27 Code' 10 


Prior Symbol: 
r'nor symbol: 


/mbol 
s ymbol 


27 Code:1 




3" Symbol 2' ~^r> 1 
3t SyffW O C^)» 1 
Symbol 2* C"0° iOiffiOOG' 


P o c yn ^ 
P o yn i 
P o nbo 


■ symbol: •• Code 11 
yr 1 01 


ro »n i 


T ynbol 


• 10 




Symbol Code 1 ' 11110 


Fno v 
no nbo 
ro ynho 


if Symbol: 27 Code: 1 




q Sv ho 

c vr ,hr 
c vrbo 


c "xio " 




Syflbot ' O^is W1 1 1 " 1 'i 
Symbol ♦ Code 0"H"1i 
Symbol ? tefe «'W 
Syrtd ? Code ' m»101 


P* y bol 


y ho f xlf 1 
&' Symbol; 27 Code: 1 


Prior Symbol: 


<j vnN) 


e "M" i" 

2 Cjd- 
' Code.1 
2 CyJ- " 


P"or "Vr"/ 


Symbol 4 Code "0O*GW 
• Symbol's Code: 1111111110 


■> Vllx 


Symbol:" Code: 010 
Syr 1 jd 11 


?i ^y b« 


s'rrivjl 
< Syrrix,! 


' Code:1 
27 Code.1 
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Prior Symbol; 

Prior symbol: 7 
Prior symbol: 7 
Pnor symbol: ia 
Pror Symbol 4 
Prior Symbol: A 



Symbol: 2? Code:0 
Symbol: ' Cods: 1 
Symbol: 27 Code: 1 
Syrrool 27 Code 10C1C 
Symbol:" Code: 11 



Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 
Prior Symbol: 
Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 
Prior Symbol: 
Pnor Symbol: 
Prior Symbol 
Pnor Symbol: 

Pno Svmbol 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Prior symbol: 
Prior Symbol: 



A Symbol: r Coise:1011 

A symbol: ! uxle: 10u01 

'B' Symbol: 27 Cede: 10010 
B' symbol: a' Cooe: 1O1 
8' Symbol: 'a' Cooe: 111 

'8' Symbol: T Code: 10011 
B' Symbol: o' Cooe.n0 
B' Symbol: r Code: 01 
B' Symbol: u' Cooe. 1000 
'C Symbol: 27 Cods: 01 110 
C' Symbol: s Code. 00 
C Symbol: K Code: 10 
V Symbol: T Code: 0111 1 
"C Symbol:' 1 .' Code: 110 
C Symbol: 'o' Code: 111 



if Code: 0110 
t V Svmbol: V Code: 0100 



Prior Symboil: 
Pnsr Symbol: 
Pnor Symbol. 
Pnor Symbol.' 
Pnor Symbol: 
Pnor Symbol: 
Prior Symbol 

Pnar Symbol: 
°rior Symbol 



■D' Symbol: 'e' Code: 101 
D Synboi f Co* 1 0! 
V 'Symbol; V Code: 1110 
D Syrobo 1 / Co* " JO 
C SyrrifOf 'J Mi 10 
fc SyfPfcoi a Code 0 0 
L S/ffW 1 code O0J 
t Sysrfwf c code ^1! 
E Symbol t Code 001 
£ Symbol t Code "'03 



£' Symbol. V 
t,T SyffiSOi: 27 Code: 
Pne Sv-ribo 1 f Sypr-hor 
D rQ Syiibo 1 F Syf*oi f Cooe '0 

•>ii/S*"ibo <3 Sywoc 27 Code 00 

P^orSvcijO & iynse s Ooue "1 
P"« Syrw) <a Syuoo T Couft 100 
P'>.f&ynvo O Synboi T Cow* 00 
PnOfSvmb" 0 Syn«oi o Code 101 
P^OfSyPDO Cf SyffbO! 
PfOrS>ooo ij symbol 
FrorSypca W byrtto 

pf » Vsc H" Synsov t cooe- *■« 
PTx Synoc H Svnbo o C:« 10 
PwSynoc H Svrnooi u C-<sc 11 1 
p!cS>nE>-' 1 Symbol 27 c-«e 011 
p-w Syrow 1 Symbol Co* 000 
PiorSynoo f Symb^i Cooe 100 
PtO'Synou I Syri*oi Cooe 005 
PlrySyiOu I S»rr%cf n Code <" 
Ploi-Sy-riOu, I Ssrrbcl Ccoc <01 
Pdc-Symeo 1 Syrroct s Code 0 4 0 
Pnor Symbol: J' Symbol: 2? Cods: 1000 
Pnor Symooi: J Symbol: . Code: 1001 



010 



100 



1010 



= 011 



Svnbu J Symbol e Code "Oi 
Svnix, J Symbol Cod» 1100 
Svmbol: 'J' Symbol: 'C Code: 0 
Svmboi: J' Symbol: v Code: 101 
Svmboi: K Symbol: 27 Code; 111 
Svmboi: K Symbol: a' Code: 1 00 
Svmboi; K' Symbol: •« 
Smbo K Synboi i 

$v"ibo L Svnboi 




P"LrS,"iboi O S^.c 1 2 
P"crs^m5oi O Sjmbr-' 
Prior Symbol: 'O' Symooi: T 
P"crsynio O Synbi.' r 



Syr>i»' f 



Pnor Symo 



P' Symbol. 

5i: V Symbol; 

■A: V Symbol: 

3i:'P' Symbol: 

ProrSyiw P Symbol 

ProrS>noc P Symbol 

pror Sy >o i Cf Symbol 
ProrSytn> K Svmbo 

ProrS>no.-> k Sv*c 
pnor S>tpo£i K Svrftc a 

P-'Sf VtW ft S»f>hO » 

P r of Symbol % Syrsbc o 

P^ofSyTiyt S Sy *a ' 

Ppsc Symso S Syr&ol 

PnofSymoc 1 S Sytta a 

P^ofSymoc S Syhbei c 

PnocSymir S Synbsr s 

Prof Svmoai S S»i*ai * 

ProrSyfoai S 5vW)0i 

Pr'orSypb.' S Sv-irtO! o 

Pror Sinbv' "S Symbol C 

PiorSynb^ v Symbol * 

Pioi'iynoi.i I Synboi » 

Fro Syno^i 1 Symbvt 2 



'3' Code:0 

•b' Codo: 10011 

rodo 1j0o 
T Code: 1101 
'0' Code: 101 
Y Code: 1100 
27 Code:1 

■' Code: 0001 



Code: 0001 
Code: 100 
Code: 00i0 




Pnor symbol: V Symbol: / 
Pnor Symbol: "v" Symooi:' 
Pnor Symbol: v Symbol: e 

Pnor Symbol. vV Symbol: 

Pnor Symbol. ">V Symbol; 'i 



Pnor Symbol . Y 
Prior Symooi: T 



Pnor Symbol: 
Prior Symbol: 
Prior Symbol; 
Pnor symbol: 

F-oi syn ^o! 
yrt be! 



- „„..„ol: 27 Cooe: 1 
' Svmbol: 27 Code; 1 
: Symbol: 27 Cooe; 1 
r Symbol; 27 Cofle; 1 
' Symbol. 27 Code: 1 

Symoa': 27 Code: 1 
3' Symbol: 27 Code: 111.501101 

I symbol:" Cooe: 11100111W 

3' Symbol:'.' Code: 1110010 

i' Symbol: 'C Cods: 11001 



s symbo 



Pnor Symbol: '3 
Prior Symbol: 'a 
Pnor Symbol: '3 
Pnor Symbol: '3 
Prior Symbol: 'a 
Pnor Symbol: a 
Tror Symbol « 
Pror Symbol 
Prior Symbol: 'a 
Pnor Symbol: 'a 
Pnor symbol: 3 
Pnor symbol: 3 
Pnor symbol; a 
Pnor symbol; b 



Pnor symbol; S 
Pnor Symbol: b: 
Pnor Symbol: If 

Pnor Symbol: 'b' 
Pnor Symbol; 'S' 
Pnor Symbol: '8' 
Pnor Symbol: 'b' 
°mr Symbo! h 
D no Syi*ot 0 
Pnor Symbol: c 
p llf/ SflM <• 

Pnor Symbol <■ 

™or symbol: £' 
™or symooi: £' 



e' Code:0( 



)' Code: 001100011 



/ Code: SI 
t Code:0C 
Code: 1 
Symbol: x' Cooe: 1 1 
Symbol y C <fc 0C 
Syratotr Code;0C 
SyfPbo! 27 Code 101000 
symbo): " CoUkoiot- 
SytftOf Ooie K1001 
sytftof a' Code 00 
Symbol b Cooe 0 0*" 
symbol- d Cose 0 0"i 

Symbol Cods '"11 
SynW 1 Cods 01OC 
SynW 0 code "0 



000"'- 



Symbo! s Cooe 10'0"1 

Symbrtry Cso»:Oli 
c yi>bU /' Cods 0"«TO 
Cod rXH» 

symto) "Sole ")30M1 
jymtol O Code 0 - SW' 
Symbol a code 1 0 
symbol c Cooe O'OO 0 

v, SyiPtgl J ax» "1 

v Synboi C»Je 

c Symboi f Co* '00' 

c Symbol Co* f0"O1 

c Symbol: 'O' Cade: 101 

c Symbol q Coda 3'W 

c Symboi - oode GOO-* 

c Symooi » Coda 30% 
c Symbol y Cods 0*00111 
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w Symbol: tf Symbol: d' Code. 01010 
ior Symbol: * Symbol: •« Code: 00 
lor Symbol, 'd' Symbol: f Code: 10100000 
ior Svmbol: 'd' Symbol: 'g' Code: 10101011 
ior Symbol; 'd' Symbol: T Code: 1011 



PnxSvubo o 

Pnor symboi: e 
Prior Symboi: e 
Prior symboi: e 



P-or Synod e 
P orSymod e 
P or Syr* I e 

Pnor Symbol: e 
Prior Symbol; 'e' 



Syirbd 



Symbol i Code '^r^(}\ 
( Symbol: V Code: 000100 
! Symbol; r Code: 100H0H 
s' Symbol: T Code: 0010 
!' Symbol; W Code: 100111 
1' Symbol: 'n' Code: 010 

Symbol j Code J0H1C 
< Symbol: p Code: 001111 
r Symbol: r Coda: 11 0 



Prior Symbol 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 

Prior Symbol: 
t>no Sy-nbol 
pfio Symbol 



PncSyito Synfiof ., code minoi 

"'m Synco, fi SynBol v cede T'VP 

°no Symbo e Symbo 1 tf Code 101111 

*i-'Svr*o & Symbol x Code 000 ,"1 

Prta'S»T*tf & S«mbo! y Code <0T1 

PnySrrM 8 Svmbe! 2 Code < 0 , 'i0">, 

°rp-S»mbo! f Syria- 27 Code 'in 11 




Of ayffltK* 

Pfior a/fPOOJ 
Pr« symbol 
Prof s/rboi 
Pr-ofS.yr"*0! 
Proftys*o> 
Prior symbol 
Prortynbo! 



9 Swt\, a » 1110 

9 syti>x> e >o° CO 

9 SyfiK) 0 Cxi" C1010'' 

9 Synixj ft C11 

9 S«n\> 1 Code V0- 

9 wr*c f C"*' ""ly 

9 1 bynbo s OMe 11000 
9' Synbo u CsOf> 1*00' 
g SyWv 010MO 
ir Sr*** 27 fiate 101118 

h S/rPbot Code 100 
h Synod Ode WX> 



PnoiSynbd 1 

Prior Symbol: '! 
Prior Symbol: '! 

Prior Symbol: 1 
Prior Symbol:'! 
"no Syrrbcl 
ni. Symbol 
^rior Symbol 
Prior Symbol: ". 
Prior Symbol: ". 

°no Syrbol 



Symbol: 'u' Cede: 101000 
Symbol:'/ Code: 1011101 
Symbol: 27 Code: 00011101 

Symbol:'.' Coos; 100110100 
Symbol:'.' Cods: 10011000 
Symbol:'? Code: 11010 
Svmbol; 'D' Code: 10011 




Prior Symbol: 

°bo Symbol 
Pro SyTibol 
Pri" S»Ti6oi 



' Symbol: s' Code: 01010 
" Symbol: T Code: 001100 
' Symbol: V Code: 1011010 
' Symboi: V Code: 101100 
: Symboi: V Code; 0100 
if Symbol: 27 Code: 101010 



Prior Symbol: 
Prior Symbol: 
Pnor Symbol: 
Prior Symbol: 



Pnor Symbol: 
Pnor Symbol: 
Pnor Symbol: 
Pnor Symboi: 
Pnor Symboi: 
Prior Symbol; 
Pnor Symboi: 

Pnor Symbol: 
Pnor Symool: 



"i SymsK Code irtci 
"1 Symbol Code '010111 
ii Symbol 3 CCe 00 
ri SymiH \ Cs* 10*00 
n Symbol e Cods Qi 
n 3/irtiotl Code "9 
n symbol it Cxfe 1vl10 
m symboi 0 Ccoe 1000 
n S/r-fcc! « Code iOO 1 
r* Sym&e! s Coco. 10" 1 ' 
<" Symboi u Code ■ , 0 < 1 
P symbol y Code 110*00 
n Symto 1 27 Code O'OOOO'" 
'ft' Symoai:" Code; 10 
r Symoo. " Code 010801 < 
r> Synbo Cbde 1 '*V0 



i Symbo n Sy*o Cods 0 



°n 'Sv"iJO> r 
P" r£,n!x> 1 
P" rSvmbo< ( 

P"orSynio r 
P*"r synbo' 1 
P^fSynboi 1 



0. t C^d* 05-101'lOJ 



byr*oi * ' 



Pnoi Synbo) 
Pior&ynW 
Pnor Symboi: 
Prix Syrrbot 
Prior Symboi: 
Prior Symbol: 
Pnor Symboi: 
Prior Symbol: 
Prior Symbol: 
Prior Symbol: 
Pnor Symbol: 
Pnor Symbol' 
Prior Symbol; 



°no. Sv-ibo 
a n^ Svnao" 



11 Syr tot 0 !>» 1"m 

i Synbot f Co^OrO' 1111 

» Synbor s, Code 010" 

i SynW Cods 1110 

n Synbei u Co* 0'00031 

i Syrroii V Co* OHO'OO 

11 Sirrbct f co£& eno'oi 

" Symboi z C«S6 OW0C 

0 Symboi Z 7 Ood^ 1010100 1 ' 

0 Symboi >d<> C01 

rf Symboi "100-11 V 

j 3/fPt,0i COvS 0100"" 

3 Sytr&oS H00110 

0 Symbol S Code 



■> SytsbOi <. C 

Sy« C 
Syenbof 3 1. 



, Sy8*oi t 



i '101000 
: 1101101 



0 Symbol p Coo* TOO 

> & Synbo s Codf i0^v1 
^ 0 Synbo t Code '00 .0 

^ Synbo v c<xSf °1 11 

j 0 Symoai » Code 10011 

- & Symso * 1 ode 101J1000 

- p Symoo 2, Co* 0"011 
■> p Symso Cod? 000 

1 p Syioo Cade 10 10910 

■> p ?ymoo SS Co^e 00' 

■> p R ym0" » Co^e 110 

n p S>mDo ti C <ie 111' 

> p 5vf"!Mi T Cooe !0 M 
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Prior Symbol: 'tf Symbol: W Code: 1010011 
Prior Symbol: 'p' Symbol:'©' Code: 0111 
Prior Symbol: 'p' Symbol: 'p' Code: 11101 
Prior Symbol: 'p' Symbol: ';* Code: 100 
Prior Symbol: y Symbol: 's' Code: 0! 100 
Prior Symbol: 'p' Symbol: T Code: 11100 
Prior Symbol: 'p' Symbol: V Code: 10101 
Prior Symbol: 'p 1 Symbol: y Code: 011010 
Prior Symbol: 'q' Symbol: 27 Code: 0 
Prior Symbol: 'q' Symbol: V Code: 1 
Prior Symbol: 'f Symbol: 27 Code: 10011111 

Priot Symbols Y Symbol: '" Code 1001 1 10 
Prior Symbol; Y SyrtboS:')' Code: 100111100 
Prior Symbol- 1 Symbol: V Code: 100100 
Prior Symfrol ';' Symbol -' Code 11001100 
Prior .Symbol*. Symbol:'.'' Code: 10001 
P"urS/Miol r Synou Code 1 00"11101 
Prior Symbol Y Symbol: '8' Code: 1101 
Prior Symbol: Y Symbol: V Code: 11001101 
P"crv/f"bo! r Synrxs c Code 1"30u1 
Prior Symbol: Y Symbol 'if Code: 11000 
Prior Symbol: Y Symbol' V Code: 101 
Prior Symbol.' Y Symbol: t Code: 1 1001 1 1 1 1 
Prior Symbol: T Symbol: V Code: 100101 
Prior SymSot Y SymBSi:T Code: 010 
Prior Symbol Y Symbol' V Cods: 110010 
Prior Symbol: V Symbol T Cods: 00100 
Prior Symbol: V Syrssot 'm' Code: 00101 
Prw Symbol v Symbol V Coos 0 1 '00 
Pnor Symbol: 'f Symbol: 'o* Code: 000 
Prior Symbol: Y Symbol V €00*11001110 
Prior Symbol: V Symbol; Y Code: 100! 10 
Prior Symbol: V Symbol:'!' Gods: 01 11 
Phot Symbol: V -Symbol' 't Code: 8011 
Prior Symbol: 'f Symbol: V Code: 100000 
Prior Symbol: r Symbol V Cods: 110011110 
Prior Symbol: T" Symbol: V CoOk 01101 
Pn r ymbrj yrrixi <!' rods 1 <*11100 
Pnor Symbol: s' Bymbol:" Coae:0 
Prior svmbol: 's' Symbol: "' Code: 1001 moo 
Prtor Symbol:'? symbol:'" Code: 10O1111O1 
°n Synbo >rrt>! 'ud- 111 11 
Prior Svmbol: 's' Symbol: V Code: 1000 
Prior Svmbol: 's' Symbol:".' Code: 11101011 
no ivibm nfr-l Code C)i' 
n« bvnbr « yrpbrl Code V i1111 
no v nbo 1 ymt I r GvAr 100 0 
pi« v >"., 1 nbol * Core 1 
~>rp bvnbo S mbol n Code 0 
Pnor svmbo!: s' Symbol; t Code: 51100 
p-i-r sy-yv""i' •-ynbol"'" Code' Will 
Pi" s noo <• ymbol "ode 111"100 

P syi i". ^ y nbol Code 1 0101H 
Pi bvmbo yrrbol o rods 



Prior Symbol: *$' Symbol 'p' Cods: 1001101 
Prtor Syaftetf? Symbol's' Gods: 11 »i 
Prior Symbol: "s* Symbol: t Code: KM 
Prior Symbol V Synbo. if Cods 110810 
Pnor Symbol V Svmboi V Code 10011 10'. 
Prior Symbot'sf. Symbol' y Cods: 18Q1100 
Prior Symbol; t Symbol: 2? Code: 11Q00011 
PnorSyirtsott Symbol" Code ill 
Prior Symbol '? Symbol " Code H000100 
Prior Symbol: t Symbol V Code 01 11 TOO 
Prior Symbol t Symbol .' Cods 01111110 
Prior Symbol: '? Symbai: '.' Code 01101 
Prior Symbol T Symbol';' Cods' 110000100 
Pnor Symbol T Symbol'* Code. 0100 
Pnor Symbol t Symbol 'b Code 110BO0101 
Prtor Symbol T Symbol; 'C Code. 11000101 
Pno'SynM f Svmboi e Code 1j1 
Poor Symbol f SyfiW W Coae 00 
Prior SymWiT Symbol'? Code: 1101 
Prior Symbol: T Symbol* Code:&li110i 
Prior Symbol: t Spttet-tet- Code: 01 1 1 1 1 1 1 
Prior Symbol: 'f Symbol TV Code 01 111 10 
Prior SpibotT Symbol; '»' Code; 100 
Pnor Symbol 'f Symbol- V Code 11001 
Prtor Symbol; 'f Symbol; '$' Cafe 01 01 
Prior Symbol f SytobO' f Co* 01 '00 
Poor Symbol T Symbol Tf Cade: 01 110 
Pits Symbol T Symbol V Code 1100000 
Pnor Symbol T Symbol y 'Socle 1100011 
Pnor Symbol V Symbol 27 Code 100 1 100 
Pnot Symbol V Symbol " Code 100000 
"nor Symbol- V Symbol's' Co*' '001 11 
Prior Symbol: v Symbol; v Code: '00801 
Pnor Symbol- V Symbol' V Co*' '000' 
p<xS>mcv t> Synbo d Code 11 100 
P*or Symooi- tf Symbol 'g Code 11101 
Prior Symbol: V Symbol: V Code 1 11 10 
Prior Symbol: V Symbol:'!' CodeMOOlO 
Prior Symbol 'tf Symbol: V Code: 1001101 
Prror Symooi: 'u' Symbol: '!' Code: 0100 
Pnor Symbol: 'u' Symbol W Code; 111111 
Prior Symbol: Tf Symbol 'n' Code: 110 
Pnor Symbol: 'if Symbol: '0' Code: 11111010 
Prior Symbol: V Symbol: 'p' Code: 0101 
Prior Symbol: V Symbol: r Code: 00 
Prior Symbol: Tf Symbol: 's' Code: 011 
Prior Symbol: V Symbol; T Code: 10i 

Prior Symbol; 'if Symbol: y Code: 1111100 
Prior Symooi: V Symbol: 27 Code: 00010 
Prior Symooi: V Symbol: a' Code. 091 
Prior Symbol: V Symbol; 'e' Code; 1 
Prior Symooi: V Symbol: 'i' Code: 01 

Prior Symbol; V Symbol: 's' Code: 000110 
Prior Symbol: V Symbol: y Code: 000111 



Prior Symbol: W Symbol. 27 Code: 011101 
Prior Symbol: W Symbol: ' ' Code: 001 
Prior Symbol: W Symbol:'.' Code: 011100 
Prior Symbol: V Symbol: s' Code: 010 
Prior Symbol: W Symbol: 'e' Code: 1110 
Prior Symbol: W Symbol: 'IY Code: 000 
Prior Symbol: V Symbol: T Code: 10 
Prior Symbol: W Symbol: T Code: 011110 
Prior Symbol: V Symbol: W Code: 011111 
Prior Symbol: V Symbol; W Code: 11111 
Prior Symbol: W Symbol: '0' Code: 110 
Prior Symbol: W Symbol: V Code: 0110 
Prior Symbol: W Symbol's Code: 11110 
Prior Symbol; Y Symbol: 27 Code: 10 
Prior Symooi: Y Symbol: " Code: 0110 
Prior Symbol:'?.' Symbol:',' Code: 0111 
Prior Symooi: Y Symbol:'-' Code: 1100 
Pnor Symbol: Y Symbol's' Code: 111 
Pnor Symbol: Y Symbol: 'e' Code: 00 
Prior Symooi: Y Symbol: V Code: 010 
Poor Symooi: Y Symbol: T Code: 1101 
Prior Symbol: y Symbol: 27 Code: 01010 
Prior Symbol; y Symbol. ' ' Code: 1 
Prior Symooi: y Symbol: '" Code: 010010 
Prior Symbol: y Symbol:'.' Code: 0001 
Prior Symooi: y Symbol:'.' Code: 0111 
Prior Symbol: y Symbol: ';' Code: 011001 
Prior Symbol: y Symbol"?' Code: 0100110 
Prior Symbol: y Symbol: 'a' Code: 010011! 
Prior Symbol: y Symbol: 'b' Code: 01 1 0000 
Prior Symbol: y Symbol: 'd' Code: 000001 
Prior Symbol.' y Symbol: 'e' Code: 0010 
Prior Symbol: y Symbol: '!' Code: 0110001 
Prior Symbol: y Symbol:'!' Code: 000010 
Prior Symbol: y Symbol: T Code: 01000 
Prior Symbol: y Symbol: 'm' Code: 000000 
Prior Symbol: y Symbol: 'rf Code: 01011 
Prior Symbol: y Symbol: 'o' Code: 01101 
Prior Symbol; y Symbol: 's' Code: 0011 
Prior Symbol, y Symbol: W Code: 000011 
Prior Symbol: t Symbol: 27 Code; 100 
Prior Symbol: t Symbol: ' ' Code: 1110 
Prior Symbol:'!' Symbol:': Code: 1111 
Prior Symbol; 'z' Symbol 'a' Code: 000 
Prior Symbol. 'r Symbol: 'e' Code: 001 
Prior Symbol: 't Symbol: 'I' Code: 1 10 
Prior Symbol: 'i Symbol: T Code: 010 
Prior Symbol: '2' Symbol: 'o' Code: 101 
Prior Symbol: 'i Symbol: Y Code: 011 
Prior Symbol: '(' Symbol: 27 Code: 1 
Prior Symbol: 1' Symbol: 27 Code: ! 
Prior Symbol:')' Symbol: 27 Code; 1 
Pnor Symbol: '~' Symbol: 27 Code: 1 
Prior Symbol: 12? Symbol: 27 Code:! 
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Table C.7 English-language Program Description Decode Table 



93 22 

94 2 

95 32 



236 6 

237 134 

238 6 



242 6 

243 184 

244 6 

245 220 

246 6 

247 236 

248 6 

249 233 



462 42 

464 43 

466 45 

467 46 

468 47 

469 225 



250 6 



268 2 
270 197 



123 SO 

124 2 

125 52 



199 206 

200 3 

201 240 



354 155 

355 155 

356 155 



21S 5 

219 36 

220 5 

221 64 

222 5 

223 118 

224 5 

225 174 

226 5 



366 183 

367 218 

368 168 



525 1 

526 2 

527 243 

528 227 

529 3 
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781 225 
783 2 ' 



855 239 

856 5 
85? 5 



558 184 

559 155 
580 160 



791 1 

792 155 

793 2 

794 225 

795 6 

796 155 

797 232 

798 233 

799 1 
SCO 242 



952 155 
954 226 



741 245 

742 2 

743 225 



923 8 

924 9 

925 228 
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103 243 

104 23 

105 24 

106 242 



123 225 

124 229 

125 233 



B 226 

1200 248 

1201 155 
[202 174 



1279 2 

1280 245 
81 3 



1433 12 

1434 13 

1435 236 



1496 173 

1497 22S 

1498 240 



1590 187 

1591 226 

1592 173 

1593 237 



1597 227 

1598 172 

1599 236 

1600 238 



1615 242 

1616 225 

1617 243 

1619 12 

1621 233 

1623 15 

1625 229 

1626 16 
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1732 2 

1733 187 

1734 3 
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Annex D 

(Informative) 

An Overview of PSIP for Terrestrial Broadcast 
with Application Examples 

The Program and System Information Protocol (PSIP) is a small collection of tables designed to 
operate within every Transport Stream for terrestrial broadcast of digital TV. Its purpose is to 
describe the information at the system and event levels for all virtual channels carried in a 
particular Transport Stream. Additionally, information for analog channels as well as digital 
channels from other Transport Streams may be incorporated. The relational hierarchy for the 
component tables is explained through typical application examples in this document. 

PSIP is the result of combining and compacting two existing optional ATSC protocols: 
A/55 and A/56. Although these protocols were individually efficient and accomplished their 
purpose, their mutual implementation was difficult due to their structural differences and their 
overlapping definitions. PSIP solves this problem. The tables defined in PSIP use packet 
identifiers (PIDs) that are different from those specified by the optional A/55 and A/56 standards. 
This provision has been included to enable the operation of existing equipment designed or 
manufactured to support A/55 and/or A/56. 

D1. INTRODUCTION 

Under the adopted ATSC standard for digital TV, the typical 6 MHz channel used for 
analog TV broadcast supports about 1 9 Mbps of throughput for terrestrial broadcast. Since 
audiovisual signals with standard resolution can be compressed using MPEG-2 to sustainable 
rates of around 6 Mbps, then around 3 or 4 digital TV channels can be safely supported in a 
single physical channel without congestion Moreover, enough bandwidth remains within the 
same Transport Stream to provide several additional low-bandwidth non-conventional services 
such as; weather reports, stock indices, headline news, software download (for games or 
enhanced applications!, image-driven classified ads, home shopping, pay-per-view information, 
and others. 

It is therefore practical to anticipate that in the future, the list of services (virtual 
channels) carried in a physical transmission channel (6 MHz of bandwidth for the U.S.) may 
easily reach ten or more. What is even more important is that the number and type of services 
may also change continuously, thus becoming a more dynamic medium than what we have today. 

An important feature of terrestrial broadcasting is that sources follow a- distributed 
information model rather than a centralized one. Unlike cable or satellite, service providers are 
geographically distributed and have no interaction with respect to data unification or even 
synchronization. It is therefore necessary to develop a protocol for describing system information 
and event descriptions which is followed by every organization in charge of a physical 
transmission channel. System information allows navigation and access to each of the channels 
within the Transport Stream, whereas event descriptions give the user content information for 
browsing and selection. 
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In this document we describe the development of a transport-based implementation of the 
PSIP protocol using examples. Our hope is to introduce the reader to the most important concepts 
and components that constitute the protocol. 

D2, ELEMENTS OF PSIP 

PSIP is a collection of hierarchically-associated tables each of which describes particular 
elements of typical digital TV services. Figures D. 1 and D.2 show the different components and 
the notation used to describe them. The packets of the base tables arc- all labeled with the base 
PID (base_PiD) which has been chosen as OxIFFB. The base tables are: the System Time Table 
(STT), the Rating Region Table (RRT), the Master Guide Table (MGT) and the Virtual Channel 
Table (VCT). 

A second set of tables are the Event Information Tables (E1T) whose packet identifiers 
(PIDs) are defined in the MGT. A third set of tables are the Extended Text Tables (ETT), and 
similarly, their packet identifiers (PIDs) are defined in the MGT. 

The System Time Table (STT) is a small data structure that fits in one packet and serves 
as a reference for time of day. Receivers can use this table as a reference for timing start times of 
advertised eyents. 

It should be noted that, except for the MGT, PSIP tables may start in any byte position 
within an MPEG-2 transport stream packet. The Master Guide Table is special in that the first 
byte always is aligned with the first byte of the packet pay load. The A/65 standard states this 
restriction as the pointerjield of the Transport Stream packet carrying the Sabiejd field of the MGT 
section shall have the value 0x00 (section starts immediately after the poinier_fieid). 

In general, table sections may span packet boundaries. Also, if the tables are small 
enough, more than one PSIP table may be present within a single transport stream packet. The 
MPEG-2 pointerjieid mechanism is used to indicate the first byte of a table within a packet 
payload. The starting byte of subsequent tables that might be in the same payload is determined 
by processing successive sectionjength fields. The location of the sectionjength field is guaranteed 
to be consistent for any type of PSIP table, as the format conforms to MPEG-2 defined Program 
Specific Information (PSI) tables. 

If a packet payload does not include the start of a table, the payioad_unit_start_indicator bit in 
the packet header is set to '0' and the pointerjield is not present. 

Transmission syntax for the United States' voluntary program rating system is included in 
this standard. The Rating Region Table (RRT) has been designed to transmit the rating standard 
in use for each country using the standard. Provisions were made for different rating systems for 
different countries and multi-country regions as well. 
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Figure 0.1 Main Structure for the PSIP Tables 



The Master Guide Table (MGT) provides general Information about all of the other tables 
that comprise the PSIP standard. It defines table sizes necessary for memory allocation during 
decoding; it defines version numbers to identify those tables that need to be updated; it has a 
constrained header location to facilitate receiver acquisition; and it gives the packet identifiers 
(PlDs) thai label the tables. 

The Virtual Channel Table (VCT), also referred to as the Terrestrial VCT (TVCT), 
contains a list of all the channels thai are or will be on-line plus their attributes. Among the 
attributes we have the channel name, navigation identifiers, stream components and types, etc. 

As part of PSIP there are several Event Information Tables, each of which describes the 
events or TV programs associated wish each of the virtual channels listed in the VCT. Each EIT 
is valid for a lime interval of 3 hours. Since the total number of EITs is 128, up to 16 days of 
programming may be advertised in advance. E1T-0 always denotes the current 3 hours of 
programming, EIT- 1 the next 3 hours, and so on. As a minimum, the first four EITs must always 
be present in every Transport Stream 

Start times for EITs are constrained to be one of the following UTC times: 0:00 
(midnight), 3:00, 6:00, 9:00, 12:00 (noon), 15:00, 18:00, and 21:00. Imposing constraints on the 
start times as well as the interval duration is necessary for the purpose of re-multiplexing. During 
re-multiplexing, BIT tables coming from several distinct Transport Streams may end up grouped 
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together or vice versa. If no constraints were imposed, re-muitiplexing equipment would have to 
parse EITs by content in real time, which is a difficult task. 

For example, consider a broadcast corporation operating in the Eastern time zone of the 
U.S. This corporation decides to carry 6 EITs (18 hours of TV program information). If at 
present, the Eastern time is 15:30 EDT (19:30 UTC), then the coverage times for the BIT tables 
are: 



Table D.l An Example of EIT Coverage Times 



EST number 


Version Num. 


Assigned P1D 


Coverage (UTC) 


Coverage (EDT) 


0 


6 


123 


18:00-21:00 


14:00- 17:00 


S 


4 


190 


21:00-24:00 


17:00-20:00 


2 


2 


237 


0:00 - 3:00 


20:00-23:00 


3 


7 


177 


3:00-6:00 


23:00-2:00 (nd) 


4 


8 


295 


6:00-9:00 


2:00 (nd)- 5:00 (nd) 


5 


35 


221 


9:00-12:00 


5:00 (nd) - 8:00 (nd) 



The abbreviation "nd" denotes next day. Before 17:00 EDT, the MOT will list the 
currently valid PIDs as: 123, 190, 237, 177, 295, and 221. At 17:00 EDT, table EIT-0 will 
become obsolete while the other ones will remain valid. At that time, the P1D list can be changed 
to 190, 237, 177, 295, 221, maintaining the version number list as 4, 2, 7, 8, 15. Therefore, by 
simply shifting the listed P1D values in the MGT, table E1T-1 can become EIT-0, table EIT-2 can 
become ElT-i, and so on. 

However, it is also possible to regenerate one or several EITs at any time for correcting 
and/or updating the content (e.g. in cases where "to be assigned'" events become known). 
Regeneration of EITs is flagged by updating version fields in the MGT. For example, if table 
EIT-2 needs to be updated at 16:17 EDT, then the new table must be transmitted with a version 
number equal to 3. Whenever the decoder monitoring the MGT detects a change in the version 
number of a table, it assumes thai the table has changed and needs to be reloaded. 
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ETT-0 

text messages 
for EJT-0 



Figure D.2 Extended Text Tables in the PSIP Hierarchy. 

As illustrated in Fig. D.2, there cars be several Extended Text Tables (ETTs), each of 
them having its PID defined in the MGT, Each Event Information Table (E1T) can have one 
ETT. Similarly, the Virtual Channel Table can have one ETT. As its name indicates, the purpose 
of an Extended Text Table (ETT) is to carry text messages. For example, for channels in the 
VCT, the messages can describe channel information, cost, coming attractions, etc. Similarly, for 
an event such as a movie listed in the EIT, the typical message is a short paragraph that describes 
the movie itself. Extended Text Tables are optional. 

In this final section paragraph we review once more the requirement list. The minimum 
amount of information required in an ATSC terrestrial digital Transport Stream is the VCT, the 
MGT, the RRT, the STT, and the first four EITs. All of the other elements are optional. 



D3. APPLICATION EXAMPLE 

For the purpose of this example, we assume that a broadcast group, here denominated 
NBZ, manages the frequency bands lor RF channels 12 and 39. The first one is its analog channel 
whereas the second one will be used for digital broadcast. According to the premises established 
in this document, NBZ must carry the PSIP tables in the digital Transport Stream of RF channel 
39. The tables must describe TV programs and other services provided on RF channel 39 but can 
also describe information for the analog RF' channel 12. 

Assume that NBZ operates in the Eastern time zone of the U.S., and that the current time- 
is 1 5:30 EDT (19:30 UTC). NBZ decides to operate in minimal configuration, therefore only the 
first four EITs need to be transmitted. As explained previously, EIT-0 must carry event 
information for the time window between 14:00 and 17:00 EDT, whereas EIT-I to EJT-3 will 
cover the subsequent 9 hours. For the first 6 hours, the following scenario applies: 
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Table D.2 The First 3-Hour Segment to be Described in VCT and EIT-0 







14:00-14:30 


14:30 -15:00 


15:00- 15:30 


15:30- 16:00 


16:00- 16:30 j 16:30-17:00 


PTC 12 
(12-0) 


NB2 


City Life 


City Life 


Travel Show 


Travel Show 


News j News 


PTC 39 
(12-1) 


NBZ 


City Life 


City Life 


Travel Show 


Travel Show 




News 


PTC 39 
(12-2) 


NBZ 


Soccer 


Golf Report 


Golf Report 


Car Racing 


Car Racing 




PTC 39 
(12-3) 


NBZ 


Secret Agent 




Lost Worlds 


Lost Worlds 


Lost Worlds 


Lost Worlds 




PTC 39 
(12-4) 


NBZ 


Headlines 


Headlines 


Headlines 


Headlines 


Headlines j Headlines 
I 


Table D,3 The Second 3-Hour Segment to be Described in VCT and EIT-1 






17:00-17:30 


! 7:30-! 8:00 


18:00- 18:30 


18:30- 19:00 


19:00-19:30 


19:30-20:00 


PTC 12 
(12-0) 


NBZ 


Music Today 


NY Comedy 


World View 


World View 






PTC 39 
(12-1) 


NBZ 


Music Today 


NY Comedy 


World View 


World View- 






PTC 39 
(12-2) 


NBZ 


Car Racing 




Sports News 


Tennis Playoffs 


Tennis Playoffs 


Tennis Playoffs 


PTC 39 
(12-3) 


NBZ 


Preview 


The Bandit 


The Bandit 


Tne Bandit 


The Bandit 


Preview 


PTC 39 
(32-4) 


NBZ 


Headlines 


Headlines 


Headlines 




Headlines 


Headlines 



Similar tables can be built for the next 6 hours (for E1T-2 and EIT-3). According to this 
scenario, NBZ broadcasts four regular digital channels (also called virtual channels and denoted 
by their major and minor channel numbers), one with the same program as the analog 
transmission, another for sports, and a third one for movies. The fourth one supports a service 
displaying headlines with text and images. 

D3. 1 The Master Guide Table (MG T) 

The purpose of the MGT is to describe everything about the other tables, listing features 
such as version numbers, table sizes, and packet identifiers (PIDs). Fig. D.3 shows a typical 
Master Guide Table indicating, in this case, the existence in the Transport Stream of a Virtual 
Channel Table, the Rating Region Table, four EITs, one Extended Text Table for channels, and 
two Extended Text Tables for events. 
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The first entry of the MGT describes the version number and size of the Virtual Channel 
Table. The second entry corresponds to an instance of the Rating Region Table. If some region's 
policy makers decided to use more than one instance of an RRT, the MGT would list each PID, 
version number, and size. Notice that the base PID (0x3 FFB) must be used for the VCT and the 
RRT instances as specified in PSIP. 

The next entries in the MGT correspond to the first four EITs that must be suppiied in the 
Transport Stream. The user is free to choose their PlDs as long as they are unique in the MGT list 
of PIDs. After the EITs, the MGT indicates the existence of an Extended Text Table for 
channels carried using PID OxlAAO. Similarly, the last two entries in the MGT signal the 
existence of two Extended Text Tables, one for E1T-0 and the other for E1T-1 . 



J MGT 
1 



iafoletype 


PID 




" " "1 
tabte size 


VCT 


Ox] FFB (base_PID) 


4 


485 bytes 


RRT - USA 


0x1 FFB (base PID) 


i 


560 bytes 


EJT-0 


OxiFDO 


6 


2730 bytes 


E1T-1 


OxiFDl 




1342 bytes 


EIT-2 


OxlDDl 




1224 bytes 


EIT-3 


0x!DB3 


7 


1382 bytes 


ETT for VCT 


OxlAAO 


21 


4232 bytes 


ETT-0 


Ox IB AO 


iO 


32420 bytes 




QxiBA'i 




42734 bytes 



Figure D.3 Content of the Master Guide Table 

Descriptors can be added for each entry as well as for the entire MGT. By using 
descriptors, future improvements can be incorporated without modifying the basic structure of 
the MGT. The MGT is like a flag table that continuously informs the decoder about the status of 
all the other tables (except the STT which has an independent function). The MGT is 
continuously monitored at the receiver to prepare and anticipate changes in the channel/event 
structure. When tables are changed at the broadcast side, their version numbers are incremented 
and the new numbers are listed in the MGT. Based on the version updates and on the memory 
requirements, the decoder can reload the newly defined tables for proper operation. 
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D3.2 The Virtual Channel Table (VCT) 

Figure D.4 shows the structure of the VCT which essentially contains the list of channels 
available in the Transport Stream. For convenience, it is possible to include analog channels and 
even other digital channels found in different Transport Streams. 

The field number_of_channeis_in_section indicates the number of channels described in one 
section of the VCT. In normal applications, as in the example being considered here, ai! channel 
information will fit into one section. However, there may be rare times when most of the physical 
channel is used to convey dozens of low-bandwidth services such as audio-only and data 
channels in addition to one video program. In those cases, the channel information may be larger 
than the VCT section limit of 1 Kbyte and therefore VCT segmentation will be required. 

For example, assuming that a physical channel conveys 20 low-bandwidth services in 
addition to a TV program, and assuming that their VCT information exceeds 1 Kbyte, then two 
or more sections may be defined. The first section may describe 12 virtual channels and the 
second 9 if such a partition leads to VCT sections with less than 1 Kbyte. 

A new VCT containing updated information can be transmitted at any time with the 
version_number increased by one. However, since a VCT describes only those channels from a 
particular Transport Stream, virtual channels added to the VCT at arbitrary times will not be 
detected by the receiver until it is tuned to that particular Transport Stream, For this reason, it is 
highly recommended that channel addition be made in advance to give the receivers the 
opportunity to scan the frequencies and detect the channel presence. 

The fields major_channei_number and minor_channel_nuinber are used for identification. The 
first one, the major channel number, is used to group all channels that are to be identified as 
belonging to a particular broadcast corporation (or particular identifying number such as 12 in 
this case). The minor channel number specifies a particular channel within the group. 

The field short_name is a seven-character name for the channel and may allow text-based 
access and navigation. The fields transport_stream_id and program_number are included to link the 
VCT with the PAT and PMT. A sequence of flags follows these fields. The flags indicate; (1) if 
the channel is hidden (e.g. for NVOD applications), (2) if the channel has a long text message in 
the VCT-ETT, and (3) if the channel is visible in general or has some conditional access 
constraints. 

After the flags, a description of the type of service offered is included, followed by the 
sourcejd, The sourcejd is simply an internal index for representing the particular logical channel. 
Event Information Tables and Extended Text Tables use this number to provide a list of 
associated events or text messages respectively. 
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VCT j L 



current_next_indicator = 1 
number_channels_in_section = 5 





minor short 


carrier 
freq. (MHz) 


channel 
TSSD 


progr. flags 


service 
type 


source 


descriptors 


12 


0 MBZ 


205.25 


OxOAAO 


OxOAAO 


analog 


20 


ch name 


12 


1 NBZD 


620.3 1 


0x0 AA1 


OxOOFl 


digital 


21 


ch_.nar.ie 
serv local. 


12 


5 NBZ-S 


620,31 


OxOAAS 


0x00F2 


digital 




ehname 
serv local. 


12 


12 NBZ-M 


620.31 


OxOAAl 


0x00F3 


digital 




chrome 

serv . local. 


12 


31 NBZ-H 


620.31 


0x0 AA ■ 


0x00F8 -- 


digital 


24 


ch name 
serv jocat. 



Tl 



Figure D.4 Content of the Virtual Channel Table 
Two descriptors are associated with the logical channels in the example, The first one is 
&xtenaed„channei„name and, as its name indicates, it gives the fail name of the channei. An 
example for channel NBZ-S could be; "NBZ Sport? and Fitness". The other one, the 
servicejocatici descriptor, is used lo list the available bit streams and their PIDs necessary to 
decode packets at the receiver. Assuming that NBZ-M offers bilingual transmission, then the 
following attributes are tabulated within its servicejoeation descriptor: 

PID_audio_1 AC-3 audio English 

P!D_audio_2 AC-3 audio Spanish 

PIDvideo MPEG-2 video No lang. 

Two VCTs may exist simultaneously in a Transport Stream: the current and the 
next VCT. The current VCT is recognized by having the flag current_nextjndicator set to i, while 
the next one has this flag set to 0. Although carrying the next VCT is optional, its use is 
recommended to give receivers advance notification of the new parameters that become 
operational during a VCT update. 

Assume for example that a Transport Stream contains a VCT with a version 
number of 6 which has been operational for 20 hours. At 10:00 p.m., a football game using much 
more bandwidth will be broadcast, and for this reason, the number of available channels and 
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PIDs will be redefined. Around 9:30 p.m., simultaneous transmission of the next VCT can start 
with a version number of 7. By continuously monitoring the MGT, a receiver can be informed 
that a next VCT is available. The receiver may want to cache the new VCT for future use. The 
receiver continues monitoring the MGT and when this table signals a version change for the 
current VCT (from 6 to 7), then the cached information can be used. 

When the VCT refers to an analog service type, the channe!_TSlD cannot refer to the 
identifier of a "Transport Stream" in the MFEG-2 sense. Analog NTSC broadcast signals can, 
however, carry a 16-bit unique identifier called a "Transmission Signal Identifier." 9 For the 
example VCT in Figure D.4. the Transmission Signal identifier for channel 12.0 is OxOAAO. A 
receiver can use the Transmission Signal ID given in the analog channel's channei_TSiD field to 
verify that the NTSC signal received at the frequency given in the VCT is actually the desired 
signal, In the case that the Transmission Signal ID is not known or not available, the channeijrsiD 
field may contain OxFFFF to indicate "unknown." 

It is recommended that the broadcaster insert into the VCT any major-minor channel that 
would be used to carry any program announced in the HIT. This means if no current program was 
using 7-7, and if a program 16 days from now was going to use 7-7, that 7-7 would be in the 
VCT. This would enable receivers to include the channel number in a program guide presented to 
the consumer. If a program is announced in the El f and the source ID for that program is not 
found in the VCT, the receiver cannot determine which "channel" to display for that program. 

Any channels in the VCT which are not currently active shall have the hidden attribute set 
to 1 and the hide _guide attribute set to 0. 

The following table shows DTV behavior for the various combinations of the hidden and 
hide_guide attributes, In the table the "x" entry indicates "don't care." A check in the "surf 
column indicates the channel is available by channel surfing and via direct channel number entry. 
A check in the "guide" column indicates that the channel may appear in the program guide 
listing. 



Table 1X4 Receiver Behavior with Hidden and Hide Guide Attributes 



hidden 


hide_guitie 


Receiver Behavior 


Description 






Surf 


Guide 




0 


X 


✓ 


/ 


Normal channel 


1 


1 






Special access only 


1 


0 




/ 


Inactive channel 



9 A method to include such a unique 16-bit "Transmission Signal ID" in the NTSC VBI is specified in the ESA-752 
specif! cation. 
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D3.3 The Event information Tables (EITs) 

The purpose of an EIT is to list all events for those channels that appear in the VCT for a 
given time window. As mentioned before, EST-0 describes the events for the first 3 hours, EIT-! 
for the next 3 hours, and so on. EIT-i and EIT-j have different PIDs as defined in the MGT. In 
PSIP, tables can have a multitude of instances. The different instances of a table share the same 
tablejd value and PID but use different table_id_extension values. 

In PSIP, an instance of EIT-k contains the list of events for a single virtual channel with a 
unique sourcejd. For this reason, the table_id_extension has been renamed as sourcejd in the EIT 
syntax. Figure D.5 shows, for example, the NBZ-S instance for EIT-0. Following similar 
procedures, the NBZD, NBZ-M, and NBZ-H instances of EIT-0 can be constructed. The process 
can be extended and repeated to obtain all of the instances for the other tables in the time 
sequence: EIT-i, EIT-2, etc. 

The three events programmed for the 3-hour period for NBZ-S are listed in Figure D.5. 
The field event jd is a number used to identify each event, if an event time period extends over 
more than one EIT, the same eventjd has to be used. The eventjd is used to link events with their 
messages defined in the ETT, and therefore it has to be unique only within a virtual channel and 
a 3-hour interval defined by EITs. The eventjd is followed by the startjime and then the 
iength_in_seconds. Notice that events can have start times before the activation time (14:00 EDT in 
this example) of the table.. The ETMjocation specifies the existence and the location of an 
Extended Text Message (ETM) for this event. ETMs are simply long textual descriptions. The 
collection of ETMs constitutes an Extended Text Table (ETT). 
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EIT-0 

source jd = 22 (NBZ-S instance) 



rsum_everitsjn_section = 3 



event 
ID 


iocal 
start 
time 


Length 
(seconds) 


ETM 
location 


title 


descriptors 


51 


12:30 


7200 


01 


Soccer Live 


content_advisory 


52 


14:30 


3600 


0G 


Golf Report 


c!osed_cap!ion 


53 


15:30 


9000 


01 


Car Racing 


content_advisory 



Figure D.5 Content of EIT-0 for NBZ-S 
An example of an ETM for the Car Racing event may be: 

"Live coverage from Indianapolis. This car race has become the 
largest single-day sporting event in the world. Two hundred laps 
of fui! action and speed." 

Several descriptors can be associated with each event. One is the content advisory 
descriptor which assigns a rating value according to one or more systems. Recall that the actual 
rating system definitions are tabulated within the RRT. Another is a closed caption descriptor 
which signals the existence of closed captioning and lists the necessary parameters for decoding. 

D3.4 The Rating Region Table (RRT) 

The Rating Region Table is a fixed data structure in the sense that its content remains 
mostly unchanged. It defines the rating standard that is applicable for each region and/or country. 
The concept of table instance introduced in the previous Section is also used for the RRT. 
Several instances of the RRT can be constructed and carried in the Transport Stream 
simultaneously. Each instance is identified by a different table_id_extension value (which becomes 
the ratir>g_region in the RRT syntax) and corresponds to one and only one particular region. Each 
instance has a different version number which is also carried in the MGT. This feature allows 
updating each instance separately. 
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Figure D.6 shows an example of one instance of an RRT, defined as the first rating region 
and carrying the MPAA standard rating system [Note that this is not the correct data for rating 
region 1 , see EIA-766 for that data definition.] Changes in the content of the RRT must be 
defined and approved by the ATSC. Each event listed in any of the EITs may carry a content 
advisory descriptor. This descriptor is an index or pointer to one or more instances of the RRT. 



RRT 

rating j-egion - ' (firsT instance") 



rating_regi0"\/iari8_text= E*3mp e' 
dimensions = i 



dimension_nanne - v^W's 




ValueS_dC;1 H&d - 7 




! value abbrev 


rating vaiue i 




"Suitable for All Ages" [ 








"Parents Strongly Cautioned" i 




"Restricted, under ! 7 must be | 




accompanied by adult" i 


5 1C NC-17" 


"No One 17 And Under Admitted ( 




to Theater" [ 


| 6 IC NR" 


"Not Rated by MPAA" 



Figure D.6 An Instance of a Rating Region Table (RRT). 



D4, PACKETiZATfON AND TRANSPORT 

In the previous sections, we have described how to construct the MOT, VCT, RRT, and 
EITs based on the typical scenario described in Tables D.l and D.2. The number of virtual 
channels described in the VCT is 5 and therefore, each EIT will have 5 instances. 

For the example, the size of the MOT is less than a hundred bytes and the VCT ranges 
between 300 to around 1500 bytes depending on the length of the text strings. Similarly, each 
EIT instance can have from 1 to about 3 Kbytes depending again on the text length. 

Typically, the MGT, STT, VCT, and each instance of the RRT and EIT will have one or 
at most a few sections. For each table, the sections are appended one after the other, and then 
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segmented into 1 84-byte packets. After adding the 4-byte MPEG-2 TS header, the packets are 
multiplexed with the others carrying audio, video, data, and any other components of the service. 
Figure D.7 illustrates this process. 



n 

Li U 



PSDOxlFFB 



MPEG-2 TS packets 



audio 
video 



tiT-i) with instances 



^ Output to h 



Figure D.7 Packetization and Transport of the PSIP tables 



D5. TUNING OPERATIONS AND TABLE ACCESS 

As described by the PSIP protocol, each Transport Stream will carry a set of tables 
describing system information and event description. For channel tuning, the first step is to 
collect the VCT from the Transport Stream which contains the current list of services available. 
Figure D.8 shows this process. 
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Transport Stream 



Virtual Channel Table (VCT) 



channel 5-7 
video: PSD-V 
audio!: PID-A'i 
audio2: PID-A2 
datal: PID-D1 
data2: PID-D2 



channel 5-1 ! 
video: PiD-VV 
audio: PID-AA 



channel 5-22 
Similar list of P1DS... 



Figure D.8 Extraction of the VCT from the Transport Stream 

Once the VCT has been collected, a user can tune to any virtua! channel present in the 
Transport Stream by referring to the major and minor channei numbers. Assuming that in this 
case, the user selects channel 5-11, then the orocess for decoding the audio and video 
components is shown in Fig. D.9. For tern st- al jn. adcast he existence of a service location 
descriptor in the VCT is mandatory and the?e"o,c tncre is .^o 'ieed to access the PAT or PMT for 
tuning to the principal television program so v ces I h'b> fca'ure has been included in PSIP to 
minimize the time required for changing x^a tuning o ch-fnols. However, PAT and PMT 
information is required to be present in the han.oort Slreani to provide MPEG-2 compliance. 
Access to data or other supplemental services ma> require cuu-s- to or monitoring of the PAT or 
PMT, Cable systems may choose not to ca \ 1. 1 ">uv *.c i. .?Mon descriptor, and therefore the 
information contained therein (minus the language coaej will be tound in the PMT in some cable 
systems. 
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Figure D,9 Acquisition of Audiovisual Components 
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Annex E 

(Informative) 

Typical Size of PSIP Tables 

The typical sizes for the PSIP tables (STT, MOT, VCT, RRT, EIT and ETT) are 
calculated in this Section. The notation used here for the different equations is listed in the Table 
E.l. 



Tabic E.l Symbols 



Symbol 


Description 


P 


number of Bits (4 10 ! 28) 


C 


ru'Tihes oi % rtuai c«a ridh (nm^g and dig td 1 ) pes EIT 


Cd 


number of digital channels per EIT 


E 


number oi c\cm : - oc-i virtua> cls-mr-cl 


R 


number of rating regions 


D 


average number of fating dimensions pet saling region 


L 


average number of rating values per rating dimension 



E1 . SYSTEM TIME TABLE (STT) 

The typical size for the STT is 20 bytes, with the assumption of having no descriptors. 

E2. MASTER GUIDE TABLE (MGT) 

The typical size for the MGT (in bytes), based on the assumptions listed in the column 
"Assumption", is shown in Table E.2 



Table E.2 Typical Size (bytes) of MGT 



Part 


Size (bytes) 


Assumption 


i M ' ■ v ... . 


12 




message body 


38+22 *P 


1. With one Terrestrial VCT. one channel ETT, one RRT 
instance, P ESTs and P event ETTs 

2. No descriptors 




50+22*P 





E3, TERRESTRIAL VIRTUAL CHANNEL TABLE (TVCT) 

The typical size of the TVCT (bytes), based on the assumptions listed in the column 
labeled "Assumption" is shown in Table E.3. 
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Table E.3 Typical TVCT Size (bytes) 



Part 


Size (.bytes) 


Assumption 


PSI header and trailer 


12 


1 . Ai! TVCT messages are carried in one section. 


message body 
extended channel name 
descriptor 


2if*C 




2, One string and one segment per string for long channel 
name text, 

3, Long channel name text is compressed by Huffman 
coding with a standard table, and the text length after 
compression is 1 0 bytes 


service location 
descriptor 


23*Cd 


4. Three elementary streams per virtual channel for digital 
channels. 


Total 


16+52*C+23*CJ 





E4. RATING REGION TABLE (RRT) 

The typical size (in bytes per rating region) of the RRT, based on the assumptions listed 
in the column "Assumption", is shown in Table E.4. 



Table E.4 Typical Size (in bytes per rating region) of RRT 



Part 


Size (bytes per 
rating region) 


Assumption 


PS! header and trailer 


S2 


1. One section only. 


message body 


25+0*04+ 26*L) 


2. One string and one segment per string for all text. 

3. Rating region name text is compressed by 
Huffman coding with a standard table, and the size 
after compression is 12 bytes. 

4. Dimension name text is compressed by Huffman 
coding with a standard table, and the size after 
compression is 4 bytes. 

5. Abbreviated rating value text is compressed by 
Huffman coding with a standard table, and the size 
after compression is 2 bytes. 

6. Rating value text is compressed by Huffman 
coding with a standard table, and the size after 
compression is 6 bytes. 

7. No descriptors. 


Total | 37+D*(14+26*L) 





E5. EVENT INFORMATION TABLE (EIT) 

The typical size of the EIT (in bytes per virtual channel per EIT), based on the 
assumptions listed in the column "Assumption", is shown in Table E.5. 
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Table E.5 Typical Size (bytes per virtual channel per EIT) of EIT 



Part 


Si/.e (bySes per virtual 
chanisc! per EIT) 


Assumption 


PS! header and srailer 


12 


!. One section only 


message body- 


2+30*E 


2. Ona string and one segment per string for title text. 

3. Title text is compressed by Huffman coding with a 
standard tabic, and the size after compression is SO 
bytes, 

4. No AC-3 and service location descriptors. 


closed captioning 
service descriptor 


9*E 


5. n'umber_of_services = 1. 


content advisory 
descriptor 


(3+R*(3+2*D))*E 


6. No rating_description_text. 


Totai j l4+(42-<-R*(3>2*D))*E j 



E6. EXTENDED TEXT TABLE (ETT) 

The typical size for the ETT (in bytes per virtual channel per EIT, or bytes per event per 
EIT), based on the assumptions listed in the column labeled "Assumptions", is shown in Table 
E.6. 



Table E.6 Typical Size (bytes per virtual channel or bytes per event) of ETT 



Part 


Size (bytes per 
virtual channel 
per EIT, or bytes 
per evens per 
EIT) 


Assumptions 


PSI header and trailer 


12 




message body 


508. 


1 . A virtual channel or an event can have one isxt string and 
one segment per string for the extended text message. 

2, Extended text message is compressed by Huffman coding 
with a standard table, and the size after compression is 
500 bytes. 


Total 


520 





E7. AN EXAMPLE FOR TERRESTRIAL BROADCAST 

Suppose that a TV provider is in charge of two physical transmission channels, one for 
analog and the other for digital services. Assume that the digital Transport Stream carries five 
virtual channels, each with 6 events in EIT-C E3T-1, E1T-2 and E1T-3. For each virtual channel 
and each event an extended text message is available. 

Regarding the Rating Region Table, suppose that a single rating region is defined with six 
dimensions and five values per dimension. Based on these assumptions, typical sizes for every 
PSIP table can be calculated. The results arc listed in Table E.7 and Tabic E.8. 
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Table E.7 Typical Sizes of PSIP tables (except ETT) for the Example 



Part 


Size in bytes (excluding 
Transport Sfreani packet 
header) 


Size in Transport Stream 
packets 


STT 


20 










TVCT 


443 


3 


RRT 


901 




Subtotal for tables identified 
by the base_P!D 


1502 


10 


EIT-0 


2136 


12 


EiT-i 


2136 


12 


EIT-2 


2)36 


12 


EIT-3 


2136 


12 


Total 


10046 


S8 



Table E.8 Typical Sizes of ETTs for the Example 



Part 


Size in bytes (excluding 
Transport Stream packet 
header) 


Size sr. Transport Stream 
packets 


Channel ETT 


^ 3120 


17 


Event ETT-0 


18720 


102 


Event ETF- 1 


18720 


102 


Event ETT-2 


18720 


102 


Event ETT-3 


18720 


102 


Total 


78000 


425 
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Annex F 

(Informative) 

An Overview of Huffman-based Text Compression 

This section describes the Huffman-based text compression and coding methods 
supported in the Program and System Information Protocol. In particular, this section: 

» Describes the partia! first-order Huffman coding used to compress PSIP text data. 
® Provides background description of finite-context Huffman coding. The mechanisms for 
generating and parsing Huffman codes are described. 

* Describes the decode tree data structure. 

» Defines the character set supported by this Standard. 

F1 , DATA COMPRESSION OVERVIEW 

Program and System Information data may use partial first-order Huffman encoding to 
compress English-language text. The Huffman-table based approach has the following features; 

• A typical firmware-resident Huffman decode table requires less than 2K of storage. 
« The encode and decode algorithms are relatively simple and fast. 

* Since first-order Huffma.fi codes are significantly influenced by language phonetics, codes 
produced from a sample of current program titles produce reasonable compression ratios 
for future program lilies, even though the future program titles may be significantly 
different from current titles. Therefore, hard-coded tables stored in receiver non-volatiie 
memory are helpful. 

The data compression approach has the following implementation characteristics: 

® Program descriptions and program titles may use different Huffman codes. Titles and 
descriptions have significantly different text characteristics; for example, program titles 
usually have an upper-case character following a space character, whereas program 
descriptions usually have a lower-case character following a space-character. 

• Hard-coded decode tables, one optimized for titles and one for descriptions, must reside 
in the receiver's non-volatiie memory. 

F2. OVERVIEW OF CONTEXT-SENSITIVE HUFFMAN CODING 

F2.1 Overview 

Each and every character does not occur with the same frequency in program titles and 
program descriptions. For example, the character "e" occurs more often than the character "x." 
With Huffman coding, the number of bits used to represent a character is inversely proportional 
to the character's usage frequency. 
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The Huffman coding compression ratio depends upon the statistical distribution of the 
characters being compressed. When character usage is uniformly distributed, no compression is 
achieved with Huffman coding. To achieve satisfactory compression, the Huffman codes are 
generated using statistics that match the data being compressed. For example, Huffman codes 
generated from Pascal computer programs would be less than ideal for compressing C programs. 
For text strings in the PSIP, program descriptions and program titles may be compressed with 
different sets of Huffman codes 

Context-sensitive Huffman coding recognizes that a character's usage statistics are 
context dependent. For example, the character "u"' has a high probability of occurrence after the 
character ''q". The "order" of the Huffman code defines the "look-back" context by which a 
character is coded. With orcier-0, each character is coded independently of the previous character. 
With order- 1, the Huffman code used to represent a given character depends upon the previous 
character, in zero-order Huffman compression, the occurrence probability of the alphabet 
elements is used to develop an optimal encoding tree. In first-order Huffman, the conditional 
probability of a character, given that the previous character is known, is used as the basis of a 
decoding tree. For this reason, while zero-order Huffman has typically a single tree, first-order 
Huffman has many, one for each character. 

Huffman compression involves the following steps: 

• Determine the statistical distribution of the characters or symbols in the source data. 

• Create Huffman codes from this statistical information. 

• Encode the source data: Translate each character into its corresponding Huffman code. 
To decompress the coded data, the data string is parsed bit-by-bit and translated to the 

original characters. To do this, the decompressor must have the correct decode table, which maps 
the Huffman codes to their corresponding characters. The following example illustrates the 
generation and decoding of Huffman codes. 

F2.2 Example 

Huffman codes are mapped to their corresponding characters using a binary tree structure. 
The leaves of this tree are the alphabet elements to be coded. The tree is produced by recursively 
summing the two nodes in the tree with the lowest usage frequency. For the following example, 
assume that an alphabet contains the following twelve characters which occur a certain number 
of times in the sample database: 
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Table F.l Example Character Set and Frequency of Character Occurrence 



Character 


Occurrence Number 


'a' 


1:44 


"b- 


66 


'c' 


30 


*d' 


30 




18 


'f 


12 


'g' 


6 


! h' 


i 




I 


T 


1 


BSC 


arbitrary 



The "escape" character is inserted into the table to handle input characters which rarely 
occur, and have no corresponding Huffman codes. In this example, no Huffman codes will be 
generated for the characters : h', T, and ']". Instead, their frequencies will be summed into the ESC 
character. Whenever one of these characters occur in the input stream, the encoder inserts the 
ESC Huffman code, then inserts the original ASCII value for that character. 

Figure F.l shows the construction of the Huffman tree from the character frequencies. 
The two nodes with the lowest frequencies, {'ESC and 'g'), are joined together, with a resulting 
node weight of (9). The next two lowest nodes, {T and the intermediate node), are then joined 
together, with the combined weight of (2!). This process continues until the tree's root node is 
formed. Once the tree is completed, the bit (1) is assigned to all right-hand branches, and the bit 
(0) is assigned to all left-hand branches. 

Decoding a Huffman string is straight- forward. Starting at the Huffman tree root, the 
decoder parses the string, bit by bit, until it reaches a leaf node. The leaf node is the decoded 
character. The decoder then moves back to the root of the Huffman tree to continue decoding the 
bit string, For example, the input string 101 1 10! 1 100010 would be decoded into ! beeaab'. 

This example uses order-0 Huffman codes. With order- 1, each character in the alphabet 
has an associated tree of Huffman codes for possible succeeding characters. The ESC character 
would be inserted into each of these order- 1 tables to handle statistically unlikely character pairs. 
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' 60 



j\ 



o i \ 1 

/ \ 

/ \ 

I \ 



o / \ 1 
/o/\ 1 

/ / V 
/ / / \ 



66 30 30 



Figure F.l Example Huffman Tree 



F2.3 Decode Tree Example 

Actual implementations of Huffman decoders need to map the trees into a suitable data 
structure that can be used by a computer or processor to traverse the tree top-down. In Annex C, 
a possible method for representing the trees was described and explicitly defined. Such a method 
is used here to build the decoding tree data for the example given in Figure F.l. Although an 
order-0 tree, this table is representative of order- 1 decode trees, except that the bytes of each 
order- 1 tree start at a byte location specified by the corresponding tree root offset (rather than 
starting at location 0). 
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Table F.2 Decode Tree Example 



Byte# 
0 (tree root; 


Left/'Righl Child Word Offset 
or Character Leaf 
225 (ASai'V + 128) 


i 


J (word offset of ngnt child) 


2 (tree node) 


226 <ASCil"b"* t- 128) 


3 


2 (word offset of right child) 


4 (tree node) 


3 (word offset of left child) 


5 


4 (word offset ef right child) 


6 (tree node) 


22? (ASCII "c" + 128) 


8 (tree node) 


228 (ASCII "d" + 128) 


9 


5 (word offset of right child) 


10 (tree node) 


230 (ASCII T + 128; 


1! 


g (word offset of right child) 


1 2 (tree node) 


23! (ASCIi "g" + 128) 


13 


?55 (ASCII "ESC" + 128) 



F2.4 Encoding/Character Decoding Examples with 1st-order Huffman tables 

As an example of using the Huffman table defined in Table C.4 in Annex C, here we 
show the procedure to encode and decode the string "The next" using the tables optimized for 
titles. The coding sequence that generates the bit stream for "The next" is described in Figure 
F.2. 
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<term> T 
T h 
h e 
e 

n 

<esc> n 
n e 
e x 
x t 
i <term> 



Figure F.2 Coding Example for the String "The next" 

The first character 'T' is encoded assuming that the previous one was a terminate 
character. The second letter 'h' is encoded based on the Huffman tree corresponding to the prior 
symbol T.' The sequence proceeds as shown in the Figure, The combination blank-space 
followed by an 'n' is not listed in the tree, thus the escape character is used to switch the coding 
process to uncompressed mode. Once in this mode, the 'n' is encoded using its standard 8-bit 
ISO Latin-1 value. After the 'n', an 'e' is encoded using the appropriate n-tree and the algorithm 
continues until reaching the final letter followed by a string-terminate character. Uncompressed 
transmission of this string requires 9 bytes, while after compression, only 39 bits, equivalent to 5 
bytes, are needed. 

Decoding requires traversing the different trees top-down. As an example, Figure F.3 
shows the tree when the prior character is 'x\ From our example, after decoding the letter 'x\ 
the remaining bit sequence is '01 010'. Traversing the x-tree top-down using this sequence shows 
that '01 ' corresponds to Y, a newly decoded character. The process now jumps to the t-tree and 
so on, to decode the remaining bits until the terminate code results. Notice that the trees can be 
obtained by examining the encoding tables or by following the semantics of the provided 
decoding tables. 



010 
0 
0 
01 



— * <esc> - ■ » 10010100 
. ASCIi code for "n" —> 01101110 
_ ... > 010 

0001001 
01 
010 
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Annex G 

(Informative) 

An Overview of PSIP for Cable 

As described in this standard, certain data specified in the Program and System 
Information Protocol (PSIP) forms a mandatory part of every ATSC-compliant digital multiplex 
signal delivered via terrestrial broadcast. Annex D provides an overview of the use of PSIP for 
the terrestrial broadcast application. This Annex supplements that discussion, focusing on the use 
of PSIP for digital cable. 

61. INTRODUCTION 

PSIP was designed, as much as possible, to be independent of the physical system used to 
deliver the MPEG-2 multiplex. Therefore, the System Time Table, Master Guide Table, Virtual 
Channel Table (VCT), and Event Information Tables and Extended Text Tables are generally 
applicable equally as well to cable as to terrestriai broadcast delivery methods. The differences 
can be summarized as follows: 

• For cable, the Cable Virtual Channel Table (CVCT) provides the VCT function, while 
the Terrestriai Virtual Channel Table (TVCT) applies for terrestrial broadcast. The 
cable VCT Includes two parameters not applicable to the terrestrial broadcast case, 
and the syntax of several parameters in the table is slightly different for cable as 
compared to the terrestrial broadcast case. The specifics are discussed in Section G2. 

* Use of the program guide portion of PSIP (EIT and ETT) for cable is considered 
optional, while it is mandatory when PSIP is used for terrestrial broadcasting. Cable 
operators are free to not provide any program guide data at ail if they so choose, or 
provide the data in a format other than PSIP if they do support an EPG, 

G2. COMPARING CVCT AND TVCT 

While the syntax of the Cable and Terrestrial VCTs are nearly identical, the Cable VCT 
has two parameters not present in the Terrestrial VCT: a "path select" bit, and a bit that can 
indicate that a given virtual channel is transported otit-of-band (OOB). Also, the semantics of the 
major and minor channel number fields and the source_id differ for the Cable VCT as compared 
with its terrestrial broadcast counterpart. 

G2.1. Path Select 

Use of the path select is required when PSIP is used in a cable network in which two 
separate physical cables are present. In such a case, the value of the path_seiect bit indicates 
whether the receiver should select the cable connected to its primary port ("path I") or the 
secondary cable ("path 2"). 
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G2.2 Out of Band 

When a cable virtual channel is flagged as being "out of band," it is carried on an out-of- 
band channel at the given cam'erjrequency. In general, out of band channels are delivered using 
different transmission formats (symbol rates, etc.) than the regular multiplexes. More than one 
standard format exists. A typical cable-ready digital TV or VCR will not process OOB data, 
unless perhaps it is in the context of an access control function such as monitoring an EMM 
stream. 

If a receiver is implemented with a dedicated OOB tuner, it can select and process the 
OOB multiplex if a user chooses a virtual channel flagged as out_of_band. Receivers not capable 
of receiving or processing data on out-of-band carriers may use the out_of_band flag as a way to 
skip or ignore them, 

G2.3 Major and Minor Channel Numbers 

When PSIP is used for terrestrial broadcast, care must be taken in the assignment of 
major and minor channel numbers to avoid conflicts. For example, the PSIP standard indicates 
that for the. US and its possessions, a terrestrial broadcaster with an existing NTSC license shall 
use a major channel number for digital services that corresponds to the NTSC RF channel 
number in present use for the analog signal. For cable, such restrictions are technically 
unnecessary. The use or potential re-assignment of a broadcaster's major channel number is 
beyond the scope of this standard. For terrestrial broadcast, the major channel number is limited 
to the range i to 99 for ATSC digital television or audio services. For cable, major channel 
numbers may range from 1 to 999. 

For minor channel numbers, broadcasters specify that zero shall be used for NTSC analog 
television services, 1 to 99 for ATSC digital television or audio only services, or 1 to 999 for data 
services. Minor channel numbers for cable, on the other hand, have no restrictions on use: they 
can range from 0 to 999 for any type of service. 

62.4 Source Ids 

The sourcejd parameter is defined identically between cable and terrestrial broadcast 
VCTs, except that for the cable case, value 0x0000 indicates that the programming source is not 
identified. Value zero is therefore valid for cable but is reserved (not presently defined) for 
terrestrial broadcast. 

A source ID with value zero is useful for cases where a cable operator wishes to define a 
channel for which no EPG data is currently available. It would also be usefisi to an operator who 
wishes not to supply EPG data at all. 

G3. IN-BAND VERSUS OUT-OF-BAND SYSTEM INFORMATION 

Cable operators often make use of one or more out-of-band (OOB) control channels. 
OOB control gives the operator nearly guaranteed access to each set-top box deployed in a cable 
network, because a dedicated tuner in each set-top remains tuned to the OOB channel 
independent of where the user might choose to tune the frequency-agile tuner while accessing 
various services. 
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Without an OOB channel, the cable operator either wouldn't be able to supply a 
uninterrupted stream of control messages to each set-top, or would be forced to carry 
(redundantly) the same control stream on each analog and digital signal, Duplicating the control 
stream this way is costly and wasteful of bandwidth. Analog channels in the network pose a 
problem because there isn't a convenient way to add a channel for control data to each NTSC 
signal, 

PSIP data on cable is provided in-hand so that cable-ready consumer electronic 
equipment can receive navigation data without having to process an OOB channel. Some custom, 
cable system-specific receiving devices may supplement the PSIP data by making use of other 
data, provided that the delivery of such data does not conflict with any requirements of the PSIP 
specification. 

G4. USING PSIP ON CABLE 

PSIP data carried on cable in-band is analogous to PSIP included In the terrestrial digital 
broadcast multiplex: a receiver can discover the structure of digital services carried on that 
multiplex by collecting the current VCT from it. A cable-ready digital TV can visit each digital 
signal on the cable, in sequence, and record from each a portion of the full cable VCT. This is 
exactly the same process a terrestrial digital broadcast receiver performs to build the terrestrial 
channel map. 

G4. 1 Terrestrial Virtual Channel Maps on Cable 

If a cable operator chooses to deploy digital cable boxes in a cable network, to properly 
support the cable- terminals, that network will need to conform to the transmission and transport 
standards defined through the Society of Cable Telecommunications Engineers (SCTE). In some 
instances, however, a small cable operator may offer a cable service in which no cable boxes are 
required. That operator may wish to implement a low-cost headend where off-air terrestrial 
broadcasts are simply received and placed onto the cable, as is done with a community antenna 
scheme such as SMATV. In some cases, signals may be shifted in frequency before being placed 
on the cable (such as to move a UHF frequency down to the VHP range). 

In cases such as these, a receiver may encounter a Terrestrial Virtual Channel "fable when 
acquiring a Transport Stream from the 7SQ. cable port on the receiver. Although that TS does not 
comply with SCTfi standards for digital cable, cable-ready receivers should nonetheless be 
designed to handle the case where a Terrestrial VCT Is found where a Cable VCT is expected. 

G4.2 Frequency Specification in the Cable VCT 

The Cable VCT specifies the frequency that the digital Transport Stream or analog NTSC 
picture carrier associated with a particular virtual channel is to be found. The frequency specified 
in the CVCT may be incorrect, however, and receivers should be designed to accommodate this 
inconsistency. 

As mentioned, one wa> in which this can occur when a small cable system or SMATV 
operator shifts the frequency ot an analog or digital signal without correcting the PSIP data, 
Another way in which it can occur is it a cable operator takes an off-air broadcast signal and does 
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not edit the PSIP data when it is modulated for cable. 

Receiving equipment should be designed to minimize reliance on the accuracy of the 
frequencies quoted in the VCT. The recommended approach involves use of a digital signal's 
Transport Stream ID (TSID) and an analog NTSC signal's Transmission Signal ID (we call this 
the analog TSID). The FCC is expected to assign each broadcast station operator in the US two 
unique TSID values, one for analog and one for digital transmission. The digital TSID is defined 
by the MPEG-2 Systems specification, ISO/IEC 13818-1. The analog TSID is defined in EIA- 
752, and is simply a 16-bit signal identifier that is carried in an Extended Data Service packet 
according to the E1A-608 Recommended Practice for Line-21 Data Service standard. 

Upon initial setup by an installer or consumer, a receiver should perform an automatic 
scan of all frequencies where analog or digital signals may be found.' 0 The frequencies used for 
the scan correspond to standard frequency plans for off-air broadcast or cable, as appropriate. 
When a signal is found at a given frequency, the receiver should take note of the analog or digital 
TSID. Although not all analog signals are required to include TSIDs, all digital transport streams 
are required to carry the unique TSID. 

Now, when asked to acquire a specific service, instead of using the frequency quoted by 
the VCT for that service, the receiver can instead use the frequency upon which it was last found. 
The only case in which this approach fails is if an analog TSID is not available — in such a case, 
the receiver must rely on the frequency quoted in the VCT. 

The data in the modulation field may also be in error unless the cable system modifies it. 
The SCTE has standardized two modulation modes for cable television transmission of digital 
television. The terrestrial broadcast PSIP shall indicate ATSC 8-VSB modulation for over-the-air 
transmission of digital television. Any receiver that does not have access to an out-of-band data 
stream indicating the modulation modes of the various carriers on the network will need to be 
designed to acquire any of the modes that may be present. In the US, 64-QAM, 256-QAM, 8- 
VSB or 16-VSB modulation may be encountered. 

G4.3 Service Location on Cable 

The service_location_descriptor() indicates the stream types, P1D and language code for each 
elementary stream that comprises a virtual channel. As mentioned, one of the differences 
Setwtcr t'ie tcnvsrul and cable is that the service_iocation_descriptor() is not required in the Cable 
V C f even i h ( ugi its use is mandatory for the Terrestrial VCT. The difference arises from the 
fdU *nat cable cvators may re-multiplex digital Transport Steams that are available to them, 
adJmg « ! dcLt.-sg services as necessary to create cable Transport Streams. A motivation for re- 
multnl^\ing is f.a t the data rate for information on cable is typically higher than that available 
*so'\ tt"tsti al or adcast transmissions, and a cable operator may wish to construct multiplexes 
that •vane L il u=e <">! the channel capacity. 

For cable, the receiver or set-top box needs to learn the structure of each service via the 
PMT which contains the same information as the servicejocation_descriptor{) [except for the 



10 It is strongly recommended that such a scan is done also when the receiver is in the "off state to refresh VCT and 
program guide data. 
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language code], ATSC multiplexes are MPEG-2 compliant, and the presence of the PMT is 
mandatory. 

A typical cable receiver or set-top box may implement a scheme where the last-used PID 
values for audio and video streams are stored with each VCT record. Initial acquisition of a 
virtual channel may be slower by as much as 400 milliseconds (the maximum interval between 
repetitions of the PMT) since the PMT will need to be processed to learn the PID values, but 
subsequent acquisitions can avoid this delay. However, one step in the acquisition process should 
always be to check the current PMT to verify that the PID values have not changed since the last 
acquisition of the service. If they have changed, the new values replace the old. 

G4.4 Analog Channel Sharing 

Some cable operators time-share certain 6-MHz slots between two analog television 
services, switching from one to the other on a daily schedule. If PSIP were to be used (out of 
band) to describe such a shared analog channel, two approaches are possible: 

1 . Define the channel as a single entity, using one source ID. The channel name may be a 
combination of the two service names, such as "WXYZ/USTV" for example. Or it could 
be a neutral name such as "Combo," Since the channel is defined as a single entity in 
PSIP, it appears as one horizontal grid line on the EPG display. 

2. Define the channel using two source IDs, one for the first source and another for the 
second. Using PSIP it would be possible to assign each source a separate channel name. 
Both would be assigned the same channel number and frequency, corresponding to the 
channel's EIA RF 6-MHz band on the cable. Use of the RF channel number is necessary 
for consistency between DTV receivers using PSIP and analog receivers that tune and 
number using the conventional analog method. On the EPG grid, each of the services are 
expected to show "Off the air" (or equivalent) during the part of the broadcast day when 
the transmission channel is being used for the other source. 

The second case represents an unusual situation for the DTV, in thai two services share 
the exact same channel number. If the user selects such a doubly-defined channel by direct entry 
of the number, the frequency is unambiguous so the DTV can tune straightforwardly. If the DTV 
would wish to display the proper channel name or program name, it must rely on the analog 
TSID to properly identify the received signal. 

In both of these cases, it is the responsibility of the cable headend to perform source 
switching as necessary to create the composite channel. 

G5. RE-MULTIPLEXING ISSUES 

As mentioned, a cable operator may wish to take incoming digital Transport Streams 
from various sources (terrestrial broadcast, satellite, or locally generated), add or delete services 
or elementary streams, and then re-combine them into output Transport Streams. If the incoming 
Transport Streams carry PSIP data, care must be taken to properly process this data in the re- 
multiplexer. 

Specifically, the re-multiplexer needs to account for any MPEG or PSIP fields or 
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G7. DATA RATES FOR PSiP ON CABLE 

The typical sizes of PSIP data In the cable application are computed here. Since the 
structure of the PSIP tables is unchanged from the terrestrial application, the analysis of table 
sizes found in Annex E of the PSIP standard applies equally well to cable, On cable, the 
service Jocaiion_descriptoiO is optional, however, so the CVCT data size may be reduced by (23 * 
Cd) where Cd represents the number of digital services in Use multiplex. 

If the CVCT is repeated at a rate of 2.5 repetitions per second, and we say that there are 
10 digital channels and one reference to an analog channel, the total data rate for each instance of 
the CVCT is; 

Rcvct = (size of CVCT in bytes) * (8 bils/byle) * (table repetition rate) = 

= (16+52* J I) * 8 * 2.5 1 1,760 bps 

If the MGT is repeated at a rate of one repetition each 150 milliseconds, and it includes 
references to EIT-0 through -3, the uatd rate for the MGT is: 

Rmgt = (size of MGT in bvtc&) * (8 bits/byte) * (table repetition rate) = 

= 138 *8 * 1 / .15 = 7360 bps 

An adjustment needs to be made to account for the fact that the MGT must be placed into 
the transport multiplex such that the first byte of the table (the tabtejd) aligns with the first byte of 
the packet payfoad. If we assume that, on average, half of the prior packet's payload (for the 
base„PlD) will be padded to create this alignment, the data rate for the padding is: 

RPAD = (number of pad bytes) * (8 bits/byte) * (MGT repetition rate) = 

= 92 *8 * 1 / , 15 = 4907 bps 

If the RRT is repeated at a rate of one repetition per minute, assuming one region with 
nine dimensions and an average of four levels per dimension, the data rate is: 

RRRT = (size of RRT in bytes) * (8 bits/byte) * (table repetition rate) = 
= (37+9*( 14+26*4)) * 8 * 1/60= 1099 * 8/60= 147 bps 
If the STT is repeated at a rate of once per second the data rate is: 

Rsrr=20 * 8 = 160 bps 
So, the total data rate for tables required for the cable application is: 
Rtotal = Rcvct + Rmgt + RPAD + Rrrt + Rstt 

= 1 1,760 + 7360 + 4907 + 147 + 160 - 19,427 kbps = 25 kbps 
The analysis can be extended to include the case that E1T/ETT is present in the multiplex 

as well. 
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1) Section 2 

Add the following text to the list of references; 

17, E1A 608A Recommended Practice for Line 21 Data Service, Electronic Industry 
Association {informative), 

18, U.S. Code of Federal Regulations (CFR) Title 47, 47CFR1 1, Emergency Alert 
System (EAS), U.S. Government Printing Office, Washington, DC 20040, 
http://www.fcc.gov/wtb/ruies.htni! (normative). 

19, Federal Information Processing Standard, FiPS Pub 6-4, Counties and Equivalent 
Entities of the U.S., Its Possessions, and Associated Areas -- 90 Aug 31, U.S. 
Government Printing Office, Washington, DC 20040, http://wwv.iti.nisi.gov/rspspubs 
(normative), 

2) Section 3.2 

Add the following acronyms to the list of Acronyms and Abbreviations: 

DCC Directed Channel Change 

DCCRR DCC Capable DTV Reference Receiver 

DCCSCT DCC Selection Code Table 
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3) Section 4.2 
Replace Table 4.2 v 



i the following table: 

Table 4.2 ID Ranges and Values 



Table ID 



Tables 



0x00 
0x01 
0x02 
Ox03-Ox3F 



IS(MEC 13818-1 Sections: 

PROGRAM ASSOCIATION TABLE (PAT) 
CONDiTSONAL ACCESS TABLE (CAT) 
TS PROGRAM MAP TABLE (PMT) 

[ISO Reserved] 



User Private Sections: 



0xC0-0xC6 



MASTER GUIDE TABLE (MOT) 

TERRESTRIAL VIRTUAL CHANNEL TABLE (TVCT) 

CABLE VIRTUAL CM ANNEJ. i ABLE (CVCT) 

RAT ING REGION 1 ABLE ■ RR'i ) 

EVENT sNi-ORMAT ION TABLE (EH) 



'IT XT i 



E (ETT) 



Ox! FEB 
0x1 FFB 
OxSFFB 
Ox i FFB 
per MOT 
per MOT 



OxCD SYSTEM TIME FABLE (STT) 




4) Section 5 

Replace the second paragraph with the following paragraph: 



The base PID (base_P!D) is an explicitly defined value (Ox I FFB) used to Identify the 
packets for the following tables for terrestrial and cable systems: The System Time Table (STT), 
the Master Guide Table (MGT), the Rating Region Table (RRT), the Virtual Channel Table 
(VCT), the optional Directed Channel Change Table (DCCT), and the optional Directed Channel 
Change Selection Code Table (DCCSCT). Several Event Information Tables {BIT) are also part 
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of the PSIP data structures, with their PIDs explicitly defined in the MOT, Figure 5.1 illustrates 
the relations between these elements. 
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5) Section 5 

Replace Figure 5.1 with the following figure: 




6) Section 5 

Replace the third paragraph with the following paragraph: 

As the name indicates, the System Time Table (STT) carries time information needed for 
any application requiring synchronization. The Rating Region Table (RRT) defines rating tables 
valid for different regions or countries. The Master Guide Table (MGT) defines sizes, PIDs, and 
version numbers for all of the relevant tables. The Virtual Channel Table (VCT) actually exists in 
two versions: one for terrestrial and a second one for cable applications. Its purpose is to tabulate 
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virtual channel attributes required for navigation and tuning. The terrestrial and cable versions 
are similar in structure, with the latter redefining the semantics of some fields pertinent to cable 
operations. The optional Directed Channel Change Table carries information necessary to 
perform a channel change to be performed at a time specified by the broadcaster. The optional 
Directed Channel Change Selection Code Table permits a broadcast program categorical 
classification table to be downloaded for use by some Directed Channel Change requests, 

7) Section 6 

Replace the text in Section 6 with the following text: 

8. SPECIFICATIONS 

This chapter describes the bit stream syntax and semantics for the System Time Table 
(SIT), Master Guide table (MOT), Virtual Channel Table (VCT), Rating Region Table (RRT), 
Event information Table (EIT), Extended Text Table (ETT), the optional Directed Channel 
Change Table (DCCT), the optional Directed Channel Change Selection Code Table (DCCSCT), 
core descriptors, and the multiple string structure. 

8) Section 6,2 

Replace table 6.3 Table Types with the following table: 



Table 6,3 Table Types 



table tvpe 


Meaning 


0x0000 


Terrestrial VCT with v,-- :\.fi-:xi... ^o.^l 


0x000 i 


f -rrotrMl \ ( S wish ; »,-;!! _.-i t - •:_..■";.;•;!:; i; 


0\0(!02 


Cable VCI with currer>t_nexi_md. , cator ; l 


0x0003 


t ,«M«-\< ! 'ifih :l r«»>: 


0x0004 


channel ETT 


0x0005 


3.KXT 


0x0006 


m:cscr 


Ox0007-0.\OOFF 


[Reserved for future ATSC usej 


0x01 00-0x0 S7F 


EIT-0 to EIT-I27 


0x0 180-0x0 IFF 


] Reserved for future ATSC uscj 


Ox0200-Ox027F 


event E I T-0 to event ETT- 127 


0x0280-0x0300 


1 Reserved for future ATSC use] 


0x030 l-0xO3FF 


RRT with !-ating_region 1-255 


Ox0400-OxOFFF 


[User private) 


Ox H)00 OxFFf T 


1 Reserved for future ATSC use! 



9) New Section 6.7 
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Renumber the existing Section 8.7 (including the changes introduced by Amendment 
No. 1 and Technical Corrigendum No. 1} to 6.9 and change all numbers from 6.7.x to 
6.9.x.. Renumber the existing Section 6.8 (including the changes introduced by 
Amendment No. 1 and Technical Corrigendum No. 1) to 6.10 and change ail numbers 
from 6.8.x to 6.10.x. Renumber Tables 6.16 through 6.26 Inclusive to Tables 6.25 
through 6.35 inclusive and add the following new subsection: 

6.7 Directed Channel Change Table (DCCT) 

The optional Directed Channel Change Table provides definitions of virtual channel 
change requests. The table permits the broadcaster to indicate when the viewing experience can 
be enhanced by a virtual channel change within or between physical channels. The requested 
channel change may be unconditional or may be based upon geographic, demographic, or 
categorical broadcast programming content selection criteria which may be specified and 
provided by the viewer to his/her "DCC capable DTV reference receiver"" (hereinafter DCCRR) 
through a menu setup type of procedure or through direct input. In the event that the viewer does 
not provide some of the Directed Channel Change T able (DCCT) setup selection criteria to the 
DCCRR, the DCCRR shall not respond to that portion of a DCC request. Additionally, if 
Directed Channel Change is not supported by a DTV reference receiver there shall be no visible 
impact on the main broadcast program perceived by the viewer. 

The following constraints apply to the Transport Stream packet carrying the DCCT: 

• PID for DCCT shall have the value Ox 1 FFB (base„PlD) 

• transport_scrambling_control bits shall have the value '00' 

• adaptation_field_control bits shall have the value '01' 

The bit stream syntax for the Directed Channel Change Table is shown in Table 6.16 

below. 



" Note: receiver implementation is optional. 
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Table 6,16 Bit Stream Syntax for the 
Directed Channel Change Table 



Syntax 


Bits 


Format 


directed cbarsnei change table section {) { 






table id 


g 


0xD3 


prWatelnd?cator° diCat0r 








1 


T 


reserved 


2 


'11' 


section !enqth 


12 




tabie id" extension 
r rv d~ 


16 


0x0000 


reserve 


5 


uimsbf 
uims 


cuirrerit ""xt ! ndi<-at r 
curren _nex sn ica or 






sec iors nurn er 


g 


0x00 


as sec iors_num er 


_ 


0x00 


pro oco _version 




f bf 






U!!T1SD 


fr^-V^d- V C T*' i++) 






° r reserved W0_V,C_C0Uri1 ' 


4 


'1111' 


dec from major chanrse! number 


10 


uinsbf 


dcc_from_minor_chanrse!.jUimber 


10 


uimsbf 


reserved 






dcc_to__majQr_charmei_j! umber 


10 


uimsbf 


dcc„to_m!nor_channel_number 


10 


uimsbf 


dcc_start_time 


32 


uimsbf 


dcc_end_time 


32 


uimsbf 


dcc_seSectiori_count 


8 


uimsbf 


for (j = 0; j < dcc_selection_count; j++) { 






d c c_s e 1 e cti o n_ty p e 


8 


uimsbf 


dcc_seiectiori_id 


64 


uimsbf 


reserved 


6 


'111111' 


dccjSescriptorsJength 


10 


uimsbf 


for (k = 0; k < N; k++) { 






descriptor!) 

} 






reserved 


6 


'111111' 


descriptors Jength 


10 


uimsbf 


for (j = 0; ] < N; j++) { 






descriptor!) 






} 

reserved 


6 


•111111' 


addit!onai_descriptorsjersgth 


10 


uimsbf 


for (i = 0; i < hi; { 






additional descriptor!) 






} 

CRC 32 

} 


32 


rpchof 
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tabiejd — This is an 8-bit field, which shall be set to 0xD3, identifying this table as the Directed 
Channel Change Table. 

section_syfstax_indfcator - — This 1-bit field shall be set to T. It denotes that the section follows 
the generic section syntax beyond the section length field, 

privatejndicator — This 1 -bit field shall be set to '1'. 

seetionjengtb — 12-bit field specifying the number of remaining bytes in this section 
immediately following the seetionjengtb field up to the end of the section, 

tablejdjsxtension — This 16-bit field shall be set to 0x0000, 

versiofwiumber — This 5-bit field is the version number of the DCC Table identified by the 
combination of fields table jd and table_id_extension. The version number shall be incremented by 1 
modulo 32 when any field in this instance of the DCC Table changes. In any case, the value of 
the version_number shall be identical to that of the corresponding entries in the MOT. 

current_next_indicator — This 1-bit indicator is always set to T for a DCCT section; the DCCT 
sent is always currently applicable, 

section_number — The value of this 8-bit field shall always be 0x00 (this table is only one section 
long), 

fastjsectionjrsumber — The value of this 8-bit field shall always be 0x00. 

protocoi_yersion — An 8-bit unsigned integer field whose function is to allow, in the future, this 
table type to carry parameters that may be structured differently than those defined In the current 
protocol. At present, the only valid value for protocoi_version is 0x00. Non-zero values of 
protoco!„version may only be processed by decoders designed to accommodate the later versions as 
they become standardized. 

dcc_vc_count — An 8-bit unsigned integer that specifies the number of virtual channels that will 
be affected by this DCC Table. This outer loop will permit the association of a DCC request with 
each virtual channel within a physical channel. 

dccJrom„major..chaiinel_,number ~- A 10-bit number in the range of 1 to 99 that represents the 
"major" channel number, as defined in section 6.3.1 Terrestrial Virtual Channel Table or 6.3.2 
Cable Virtual Channel Table. The specified dcc_from_major_channei_number must, be a major 
channel currently defined in the VCT and may have the attribute of hidden. The 
dcc_from_major_channel_number together with the dcc_from_minor_channe!_number fully identifies the 
virtual channei that must be currently tuned in order that the DCC request may be in effect. 

dccjromjriinor_channel_niimber A 1 0-bit number in the range of 1 to 999 that represents the 

"minor" or "sub-" virtual channel number, as defined in section 6.3.1 Terrestrial Virtual Channei 
Table or 6.3.2 Cable Virtual Channei Table. The specified dcc_from_minor_channet„number must be 
a minor channei currently defined in the VCT and may have the attribute of hidden. The 
dco_from_minor_channei_numtier together with the dcc_from_major_channel_number fully identifies the 
virtual channel that must be currently tuned in order that the DCC request may be in effect. 

dcc_to_major_channel_number A i 0-bit number in the range of 1 to 99 that represents the 

"major" channel number, as defined in section 6.3.1 Terrestrial Virtual Channel Table or 6.3.2 
Cable Virtual Channel Table, The specified dccjo_major_channel_number must be a major channel 
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currently defined in the VCT and may have the attribute of hidden. The 
dcc_to_major_channel_number together with the dcc_to_rnmor_channel_number fully identifies the virtual 
channel to which the DCCRR is requested to tune when the DCC request is in effect. 

dcc_to_minor_channel_number — A J 0-bit number in ibe range of 1 to 999 that represents the 
"minor" or "sub-" virtual channel number, as defined in section 6.3.1 Terrestrial Virtual Channel 
Table or 6.3.2 Cable Virtual Channel "fable. The specified dcc_to„minor_chartnel_nurriber must be a 
minor channel currently defined in the VCT and may have the attribute of hidden. The 
dcc_to_minor_channel_number together with the doc_to_major_channel_number fully identifies the virtual 
channel to which the DCCRR is requested to tune when the DCC request is in effect. 

dcc_start_time — A 32-bit unsigned integer quantity representing the start time of this request as 
the number of GPS seconds since 00:00:00 UTC, January 6th, 1980. This shall specify the start 
time of the time interval during which the DCC request may be in effect. 

dcc_endjime — A 32-bit unsigned integer quantity representing the end time of this request as 
the number of GPS seconds since 00:00:00 UTC, January 6th, 1980. This shall specify the end 
time of the time interval during which the DCC request may be in effect. 

dcc_seieciiGn_coiir!t -— This 8-bit unsigned Integer specifies the number of dcc_select!on_types and 
dcc_seiection_ids to be associated with 'the directed channel change request. The directed channel 
change request shall be in effect whenever the DCCRR is tuned to the dcc_from„<*anneLnumber, 
the current time is between the dcc_s»art..5ime and the dcc..end_tirr.e, and one or more of the selection 
conditions in the loop may be valid. 



dcc_seiectionjype — This 8-bit unsigned integer specifies the type of the value contained within 
the dcc_selection_id and shall have the values listed in Table 6. 3 7. 
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Table 6.17 DCC Selection Type Assignments 


Value 


Meaning 


* 0x00 


A'. ;c lis- ' : [ ? 'ip cr m JO i-?n-.T i Va s i 0'. '.'wd 


*0xG1 


Value is a specific 01 range of numeric character postal codes in the range 0000000* to 

00099999, 


0x02 


Value is an aHfAmumm r>wa-W" p«'ita. c-J(- cc-nr-' •«•"••£! 3 "ha^tfc'S 


*0xQ3 


Value is a Program identifier conforming to ATSC A/57 (Ref. |5j} provider_.index, 
program_event_id, and segment_index fields oi the program. ideittifier..descriptoi. 


0x04 


Reserved. 


0x05 


Value is an unsigned demographic selection bit field with a logical AND of a non-zero result 
selection. 


0x06 


Value unsigned djiToo.aun:-; ^fuj* „■* '.c'-f ' ! i .? ^C'v-j 1 <OR a zee :.?suir s^ccnon 


0x07 


vllueif a^^ " "* 






0x00 


A secondary redirect switch triggered upon detection of a failure to be authorized to ^maln on the 
requested "from" major/minor channel. Value is not used. Subsequent destination channel 
conditions and possibilities are contained within the descriptor loop. 


OxQA 


A departing request action is requested in case the viewer switches away from the specified 
"from'' major and minor channel number 


0x08 


An arriving request action is revested in case the viewer switches into the specified "to" major 
and minor channel number. 


OxOC 


Value is a ioc.ation_code conforming to the staie_code. couniy_sij&diVision, and county_cocte 


OxOO 


Switch if value is greater than or equal to stored value Value is a rating_va!ue as described in the 
Content Advisory Descriptor 


OxOE 


Switch if value is less than or equal to stored value. Value is a rating_value as described in the 
Content Advisory Descriptor 


" OxOF 


A return to previous Virtual Channel is requested if engaged in a DCC Fequest Value is not used. 


0x10 


Reserved. 


* 0x11 


Value is a specific or range ot numeric character postal codes in the range 00000001 to 
00089999 used in a iogtoat M©T exclusion selection. 


0;<12 


Value is an alphanumeric character postal code comprising 8 characters used in a logical NOT 
exclusion selection. 


0x13-0x14 


Reserved 


0x15 


Value is an unsigned demographic selection bit field with a logical NOT AND of a non-zero result 
select ion. 


0x16 


Value is an unsigned demographic selection pit field with a logical NOT XOR of a zero result 
selection. 


0x1? 


VAl-j-i i\ i vXn-ot -\ Sssie-ci t-^ :-oo«» f w.t'-! lC"jicai M 1 .- ''NO ■:> non :: eso <*■■.!■ m ..liis-onon 


0x18 


j'i -j." 'f-C. ' 1 ".!■"'».»'/.'. '. 'VI 'i/i'i/'to'r.'! 


Ox"! 9-0x1 B 


Reserved 


0x1 C 


Value is the iogicai NOT of a iocation_code conforming to the state_code, county _Bubdivtsion j 
and countv code. 


0x1D-0x1F 


Reserved 


4 0x2O~Qx27 


A switch based on Viewer-Direct-Select 0-7 is requested. Value is not used. 


0x2S-0x?F 




OxSO-OxFF 


Private. 



NOTE: Items marked with an asterisk (*) above are requited within a OTV device providing minima! 
support for Directed Channel Change within the United States. 
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dcc_seSection_id — This 64-bit unsigned integer contains the data identified by the 
dcc_selection_type field, and is described below. Note: 8 bit characters specified for use within this 
section shall mean characters defined in ANSI/ISO 8859-1, "8-Bit Single-Byte Coded Graphic 
Character Sets -- Part 1 : Latin Alphabet No. 1". 

If the dcc_selection_type is specified to be of type "unconditional" (0x00), the dcc_selection_id shall 
be 0x00 and the DCCRR shall unconditionally switch to the dcc_to_major_channei_number and 
dcc_to_minor_channei_number at the specified dcc_startjime. 

If the dcc_selection_type is specified to be of type 0x01 or Ox! S, the dcc_selection_id shall consist of a 
right justified five numeric 8-bit ASCII character postal code field in the range of 00001 to 99999 
padded on the left with "0" or 0x30 characters. The DCCRR shall compare that value to a stored 
representation of a numeric postal code entered by the user from setup menus within the DCCRR 
to determine if there is a match. If a match occurs, the DCCRR shall switch to the virtual channel 
specified in the dcc_to_major_channel_number and dcc_to_minor_channel_number fields at the specific 
dcc_start_time. If a question mark ("?" or 0x3F) character appears in any of the five least 
significant numeric character positions, thai position shall be considered to be a wildcard which 
will permit a selection on any numeric digit within that position. For example 00055798 would 
permit matches on 00055098 through 00055998. Similarly, 00055??8 would permit matches on 
00055008 through 00055998. Note that the special case 00000000 is not a valid postal code. 
Note that multiple numeric postal code specifications may be made within a single DCCT by 
means of the dcc_selection_count loop, if the dcc_selection_type is defined to be of type 0x1 1, the 
selection of possible postal codes would consist of the logical remainder set of all possible postal 
codes NOT previously excluded by prior dcc_seiection_type 0x1 1 types specified within this DCC 
request, if any. 

If the cicG._seiection_.iype is specified to be of type 0x02 or 0x12, the dcc_seiection_id shall consist of a 
right justified eight alphanumeric and special 8-bit ASCII character postal code field of 
unspecified format padded on the left with space characters (0x20). The field may also contain 
separator characters, as necessary, to format the postal code according to country conventions. 
The separator characters may consist of any of the following special characters: comma (0x2C), 
dash (0x2 D), period (0\2E). slash (0x2 F) or space (0x30). The separator characters shall be 
considered to be "do not care" placeholders for purposes of logical comparison to a postal code 
stored within the DTV device. The DCCRR shall compare that value to a stored representation of 
a postal code entered by the user from setup menus within the DCCRR to determine if there is a 
match. If a match occurs, the DCCRR shall switch to the virtual channel specified in the 
dccjo_,flnajor_channel_number and dccJo_minor_channei_number fields at the specific dcc_start_time. The 
alphanumeric and special characters permitted shall be any printing character within the ASCII 
character set from 0x20 through 0x7E inclusive. If a question mark ("?" or 0x3 F) character 
appears In any of the eight character positions, that position shall be considered to be a wildcard 
which will permit a selection on any character within that position. For example " 5B3-5Q?" 
would permit matches on 5B3-5Q0 through 5B3-5Q9 assuming the postal format convention was 
a numeric character in the rightmost character position. Similarly, " 5B3-573" would permit 
matches on 5B3-5A3 through 5B3-5Z3 assuming the postal format convention for the second 
from the rightmost character is alphabetic. Note that multiple postal codes may be specified 
within a single DCCT by means of the dcc_seiection_coiint loop. If the dcc_selection_type is defined to 
be of type 0x12, the selection of possible postal codes would consist of the logical remainder set 
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of all possible postal codes NOT previously excluded by prior dcc_selection_type 0x12 types 
specified within this DCC request, if any. 

If the dcc_selection_type is specified to be of type0x03, the dcc_se!ection_id shall begin with a 16 bit 
field (uimsbf) (represented as iiii in the Value in Table 6.18) left justified in the 64 bit 
dcc_seiection_id field. This initial field shall correspond to the providerjndex field of the 
program_identifier_descriptor defined in Ref. [5], The next 24 bits of the 64 bit dcc_selection_id field 
(represented as pppppp in the Value in Table 6.18) shall correspond to the program_event_id field of 
the programjdentifier_descriptor defined in Ref. [5]. The next 4 bits of the 64 bit dcc_selection_id 
(represented as s in the Value in Table 6.18) shall correspond to the segmentjndex field of the 
program _identifier_descriptor to be defined in a forthcoming revision to Ref. [5]. If the segmentjndex 
portion of the dcc_se!ection_id field is non-zero, any of dcc_selection_type values from 0x20 through 
0x27 is present, and the viewer makes or has made a selection using a DCC "Viewer-Direct- 
Select" function (see dcc_selectionjype 0x20-0x27 below), a DCCRR offering persistence of 
selections shall, upon viewer command, store the value of the most significant 44 bits of 
dcc_seiection_id together with the number of the DCC Viewer-Direct-Select function the viewer 
has selected. Upon future appearance of the same set of values of the most significant 44 bits of 
dcc_selection_id, the DCCRR shall execute a function equivalent to the DCC Viewer-Direct-Select 
function selected by the viewer on the prior occasion the particular broadcast program was 
processed by the DCCRR, In this case, the DCCRR shall switch to the virtual channel specified 
in the dcx;_to_major_channel_number and dcc_to_minor_channel_number fields at the specific 
dcc_start_time associated with the DCC Viewer-Direct-Select function having the same number as 
that selected by the viewer on the prior occasion when the selection was stored. If the 
dcc_seiection_type is defined to be of type 0x03, the BIT associated with this request must also 
contain a matching program_ideritifier_descriptor. 



Table 6.18 Program Identifier Format 



Value 




Oxiiiippppppsxxxxx 


provider/program/segment id 



If dcc_selection_type is equal to 0x05, 0x06, 0x15, or 0x16, the dcc_selection_id shall be specified to 
be a demographic selection bit field as described in Table 6.19 below. The DCCRR shall 
compare the value to a stored value which had been entered by the user within setup menus to 
determine if there is a match. 
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Table 6.19 Demographic Selection Type Assignments 



Value 


I Mea 


ring 


0x0000000000000001 


! Males 




0x0000000000000002 


| Females 




0x0000000000000004 


| Ages 2-5 




0x0000000000000008 


| Ages 6-11 




0x0000000000000010 


| Ages 12-17 




0x0000000000000020 


i Ages 1 8-34 




0x0000000000000040 


| Ages 35-49 




0x0000000000000080 


i Ages 50-54 




0x0000000000000100 


~j Ages 55-84 




0x0000000000000200 


Ages 65+ 




0x0000000000000400 


! Working 




0x0000000000000800 - 0x800000000 


3000000 1 Reserved 





If the selection is specified to be of type AND (dcc_seiection_type 0x05) with a non-zero result, the 
received dcc_seiection_id will be logically bitwise ANDed with the DCCRR's stored value. If the 
result is non zero, the DCCRR shall switch to the virtual channel specified in the 
dcc_to_major_channe!_number and dcc_to_minor_channel_number fields at the specified dcc_start_time. 
Logical ANDing with a non zero result will permit selection based upon at least one and possibly 
more selection criteria. In other words, switch if any of the criteria are selected by the viewer. If 
the deselection. type is defined to be of type 0x15, the selection would consist of the logical 
remainder set of ail possible selections NOT previously excluded by prior selections of type 0x15 
within this DCC request, if any. 

If the selection is specified to be of type XOR (dcc_setection_type 0x06) with a zero result, the 
received dcc_seieciion_id will be logically bitwise exclusive or'd with the DCCRR's stored value, 
if the result is zero, the DCCRR shall switch to the virtual channel specified in the 
dec_tQ_raa]Qf_channel_number and acc_tojnmor_channel_number fields at the specified dco_start_time. 
Logical XORing with a zero result will permit selection based upon the exact selection criteria. 
In other words, switch n ana only if the precisely matching criteria have been selected by the 
viewer, if the dcc_seleciion_type is defined to be of type 0x16, the selection would consist of the 
logical remainder set of all possible selections NOT previously excluded by prior selections of 
type 0x16 within this DCC request, if any. 

If dcc_selection_type is equal to 0x07, 0x08, 0x17, or 0x18, the dcc_selection_id shall be specified to 
be a categorical selection code field. The DCCRR shall compare the code values obtained from 
the da;_selectiori_id field to stored values which had been entered by the user through selection 
setup menus to determine if there is a match. Bach occurrence of the dcc_selection_id may contain 
up to eight categorical selection codes, each code having a length of eight bits. 

If the categorical selection is specified to be of type AND (dcc_.seiection_.type 0x07) with a non- 
zero result, the received dcc_.seiection_.id will be parsed to obtain non-zero category codes and then 
logically bitwise ANDed with the DCCRR's stored value(s). If the result is non zero, the 
DCCRR shall switch to the virtual channel specified in the dcc_to_major_channel_number and 
dcc_to_minor_channel_number fields at the specified dcc_start_time. Logical ANDing with a non zero 
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result will permit selection based upon at least one and possibly more selection criteria, In other 
words, switch if any of the criteria are selected by the viewer. If the dcc_selection_type is defined to 
be of type 0x17, the selection would consist of the logical remainder set of all possible selections 
NOT previously excluded by prior selections of type Ox 17 within this DCC request, if any. 

If the categorical selection is specified to be of type XOR (dcc_se!ection_type 0x08) with a zero 
result, the received dcc_seiection_id will be parsed to obtain non-zero category codes and then 
logically bitwise exclusive or'd with the DCCRR's stored value(s). If the result is zero, the 
DCCRR shall switch to the virtual channel specified in the dcc_to_major_channel_number and 
dcc_to_minor_channel_number fields at the specified dcc_start_time. Logical XORing with a zero result 
will permit selection based upon the exact selection criteria. In other words, switch if and only if 
the precisely matching criteria have been selected by the viewer. If the dcc_seiection_type is 
specified to be of type 0x18, the selection would consist of the logical remainder set of all 
possible selections NOT previously excluded by prior selections of type 0x18 within this DCC 
request, if any. 

Up to a maximum of eight of the 8-bit wide categorical selection codes shall be right justified 
and packed into the dcc_seiection_id 64-bit field. Each of the categorical selection codes shall 
consist of the values 0x01 through OxFF. If a code is not specified, the value of 0x00 shall be 
used as a place holder. There is a significance to the left/right order of the packing of the codes, 
The rightmost, or least significant, code shall be one of codes from the "Basic" group (codes 
0x20 through 0x26 defined in Table 6.24). The next most significant code may be one or more of 
the "Detail" group codes (0x27 through OxAD) in a sorted order that may indicate amount of 
subject material contained within the broadcast program. Table 6.20 below illustrates the 
categorical selection criteria code packing within the dcc_selection_id field. 



Table 6.20 Examples of Selection Code Packing 





Meaning 


OxOOOOOOOOOOOOGOOO 


no codes specified 


0x0000000000222120 


3 codes in least significant 24 bits 


0x0000000052304120 


4 codes in ieasi significant 32 bits 


0x303 13233343£>3620 


8 codes in 64 bits 



If the dcc_selection_type is specified to be of type 0x09, and if the DCCRR is tuned by the viewer 
to a major and minor channel number specified by the dcc_from_major_channei_niirnber and the 
dcc_from_minor_channel_number for which the viewer is not authorized, the DCCRR shall 
immediately, upon determination of the unauthorized status, tune to the 
dcc_to_major_channel_number and dcc_to_minor_channel_number. The action of this mechanism 
provides an ability to "redirect" viewers to an alternate channel in the event they are not 
authorized to view the requested channel for any reason. 

If the dcc_selection_type is specified to be of type OxOA and if the DCCRR switches out of the 
major and minor channel number specified in dcc_from_major_channe!_number and 
dcc_fromjminor_channel_number, the DCCRR shall execute the requested function specified within 
the descriptor loop defined in 6.9.11. The values within dcc_to_major_channel_number and 
dcc_to_minor_channel_number are set to "do not care" values which shall be ignored by the DCCRR. 
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If the dcc_seiection_type is specified to be of type OxOB, the DCCRR shall execute the requested 
function specified within the descriptor loop defined in 6.9.12 when the DCCRR switches into 
the major and minor channel number specified in dcc_to_major_channel_number and 
dcc_to_minor_channel_number. The values within dcc„from__major_channel_r!umber and 
dcc_from_minor_channel_number are set to "do not care" values which shall be ignored by the 
DCCRR. 

iocatiors_code — This 24-bit unsigned integer field contains siate„code, county_subdivision, and 
coursty_code sub fields (defined below) used in identification of a geographic location. 

If the dcc_seiection_type is specified to be of type OxOC or OxlC, the DCCRR shall interpret the 
dcG_seiectlonjd as a right justified 0 padded packing of the 24-bit iocaiion_code field within the 64- 
bit dcc_selection_id field as shown in Table 6,21 below. If the dcc_selection_type is specified to be of 
type OxlC, the selection would consist of the logical remainder set of all possible locations NOT 
previously excluded by prior selections of type OxlC within this DCC request, if any. The 
location_code fields are described in Table 6.21 below. 



Table 6.21 Conditional Type Value Format 



Syntax 


Bits 


Format 


dcc_selection_type { 






pad 


40 


0x00 


location_code { 






state_code 


8 


iflmsbf range 0..99 


county_subdivision 


4 


uimsbf range 0..9 


reserved 


2 




county_code 

} 

} 


10 


uimsbf rang 0 .999 



state_code — This 8-bit unsigned integer in the range 0 to 99 specifies the State or Territory. 
state_code is coded according to State and Territory FIPS number codes (see 47 CFR 1 1.15(f).). A 
value of 0 specifies all states and territories. 

county_s«bdsvision — This 4-bit unsigned integer in the range 0 to 9 specifies county subdivisions 
as shown in Table 6,22 
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Table 6.22 County Subdivision Coding 



co«fity_sub<iiv!sion 


Meaning 


GxO 


A!! or an unspecified portion of a county 




Northwest 




North Centra! 


0x3 


Ni t* ■\> -' 


0x4 


WestCenttai 


0x5 


Centra! 


0x6 


East Centra! 


0x7 


Soutnwes! 


0x8 


Sooth Central 


0x9 


Southeast 


OxA-F 


[Reset <?i ] 



county_eode — This i 0-bit unsigned integer in the range 0 to 999 specifies a county within a 
state. county_cocie is coded according to State and Territory Federal Information Processing 
Standard (FIPS) number codes maintained by the National Institute of Standards and Technology 
(NIST) in FiPS PUB 6-4. A value ofO specifies the entire state or territory. 

If the dcc_seiection_type is specified to be of type OxOD or OxOE, the DCCRR shall interpret the 
dcc_.se!ection.jd as a right justified 0 padded packing of a single 4-bit r3tmg_value field (specified in 
Section. 6.9,4 of this document describing the Content Advisory Descriptor} within the 64-bit 
dco_selection_id field. If the dcc_se!ection_type is specified to be of type OxOD the DCCRR shall 
perform a channel change if the rating_va!ue specified by the viewer and stored within the DCCRR 
is greater than or equal to the value sent within the least significant 4 bits of the dcc_seiection_id in 
this DCC request. If the dcc_seiection_type is specified to be of type OxOE the DCCRR shall 
perform a channel change if the rating... value specified by the viewer and stored within the DCCRR 
is less than or equal to the value sent within least significant 4 bits of the dce_seieef!onjd in this 
DCC request. 

If the dcc_seteciiofijype is specified to be of type OxOF, and if the DCCRR is engaged in a DCC 
request, the DTV shall tune back to the channel from which it was previously directed (the 
previous dcc_fromjnajor_cha(tneLf»umber and doc_from_;iTHftor_d?annel_number). 

If the dcc_se!ect!on_type is specified to be of type 0x20 through 0x27, the DCCRR shall tune to the 
virtual channel specified in the dC£jo_m3jor..channe!_.rturpber and cicc_to_minor_channel_number based 
upon the viewer's selection of one of eight "Vievvcr-Dircct-Select" function buttons (or 
equivalent). For example, if the viewer chooses V iewer-Direct-Seleci Button 2 and a DCC 
request has been defined for that button, the DCCRR shall immediately switch to that major and 
minor channel number when the viewer presses the button (or in some fashion chooses the 
function) regardless of other conditions, satisfied or not, associated with the DCC request. 

dcc_seiec«o!i_id — This 64-bit unsigned integer contains the data identified by the 
dcc_seiection_type field which has been described above. 

crc_32 — This is a 32 -bit field that contains the CRC value that ensures a zero output from the 
registers in the decoder defined in Annex A of ISO/lEC 13818-1 "MPEG-2 Systems" after 
processing the entire Directed Channel Change fable section. 
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hide_guide ■ — The hide_guide bit found within the VCT should be set to 1 to prevent hidden 
channels used within a DCC request from being displayed in EPG displays. 

10) New Section 6.8 

Add the following new subsection: 

6.8 DCC Selection Code Table (DCCSCT) 

The optional Directed Channel Change Selection Code Table (DCCSCT) carries code values and 
selection criteria name information for use with categorical selection code processing in the 
Directed Channel Change Table. Additionally, the DCCSCT is used to transmit descriptors 
containing location code and name data for subsequent download into storage within a DCCRR. 

The following constraints apply to the Transport Stream packets carrying the DCCSCT sections. 

• PID shall have the value Ox I FFB (base_PiD) 

• transport_scrambling_control bits shall have the value '00' 

• adap}ation_fieid„control bits shall have the value '0 I ' 

The bit stream syntax for the Directed Channel Change Selection Code Table is shown in Table 
6.23. 

tabiejd — This is an 8-bit field, which shall be set to 0xD4, identifying this table as the DCC 
Selection Code Table (DCCSCT). 

sectionjsyritaxjriciseatar — This I -bit field shall be set to '1'. It denotes that the section follows 
the generic section syntax beyond the section length field. 

privatejndscator — This 1-bit field shall be set to '1 '. 

sectionjength — 12-bit field specifying the number of remaining bytes in this section 
immediately following the sectionjength field up to the end of the section. 
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Table 6.23 Bit Stream Syntax for the DCC Selection Code Table 





Bsts 


Format 


dee_se!eeti0ft_cGde_tab!e_section {} { 






tabiejd 


8 


0xD4 


sectiosi_syntax indicator 


1 


'V 


privatejndicator 


1 


'1' 


reserved 


2 


'11' 


sectionjength 


12 


uimsbf 


tablcJd_extension 


16 


uimsbf 


reserved 


2 


'11' 


version number 


5 


uimsbf 


current_next_mdicator 




'1' 


section .number 


8 


0x00 


last .section, number 


8 


0x00 


p!otoco!_version 


8 


uimsbf 


selection, categories., defi tied 


8 


uimsbf 


for(i = 0; i < seiection_categaries_defined; { 








g 


uimsbf 


selection ^category ...name Jength 


8 


uimsbf 


seleetion_eategory_narne_texti) 






reserved 




'111111' 


descriptorsjersgth 


10 


uimsbf 


for (j = 0; j < N; j++) { 






descriptors*,) 

} 






reserved 


6 


'111111' 


addit!onai_descriptors Jength 


10 


uimsbf 


for (i = 0; i < N; { 






additiorsai_descriptors() 






} 

CRC 32 

} 


32 


rpchof 



tabSe_id_extension — A 1 6-bit unsigned integer field whose value specifies the type of information 
contained within the selection category loop. A table_id_extension value of 0x0000 specifies that 
the information contained within the selection category loop is associated with selection 
categories. A tab!e_id_extension value of 0x0001 specifies that the information contained within the 
inner descriptor loop is a decj6eation_code_descriptor. 

If the tab!e_id_extension is specified as 0x0001 to indicate that location code information is being 
sent, the selectiort_category_code should be set to OxFF, the selection_category_name_length set to 0x00, 
and the selection..category._n3me..text field may be empty because no categorical information is being 
transmitted within this instance of the table. At least one dccjocation_code_descriptor, as defined in 
section 6.9.13 below should appear within the inner descriptor loop. 

version_number --■ This 5-bit field is the version number of the DCCSC Table identified by 
combination of the fields tabtejd and tabtejd.. extension. The version number shall be incremented 
by 1 modulo 32 when any field in this instance of the DCC Selection Code Table changes. In any 
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case, the value of the version_number shall be identical to that of the corresponding entries in the 
MOT. 

cijrrent_next„indicator — This 1 -bit indicator is always set to 4 F. 
sectioiwiumber — The value of this 8-bit field shad always be 0x00. 
Sast_section_number — The value of this 8-bit field shall always be 0x00. 

protoeoLversiori — An 8-bit unsigned integer field whose function is to allow, in the future, this 
table type to carry parameters that may be structured differently than those defined in the current 
protocol. At present, the only valid value for protocol_version is 0x00. Non-zero values of 
protocoLverslon may only be processed by decoders designed to accommodate the later versions as 
they become standardized. 

sefection_categories_defir!eci — An 8-bit unsigned integer number that specifies the total number 
of entries in the category table to follow. 

se!ection_category_eode — An 8-bit unsigned integer number that specifies the value of the 
category code. The categorical selection codes conform to the initial Program Type codes 
specified in the Program Type packet (0x04) of the Extended Data Service Packets specified in 
EIA-608A, however that initial list has been extended by the list provided within the DCCSCT of 
this standard. Additionally, the fist may be further extended in the future by revision to this 
standard and the contents of the DCCSCT. Currently specified category codes are listed in Table 
6.24 below. 

it should be noted that this table is to be downloaded to the DCCRR and should not be hard 
coded. Additionally, provision has been made for the inclusion of additional generic codes in the 
future (.similar to those assigned to values 0x20 through 0x26 in the Basic group) in the range of 
OxFO through OxFE. 

A selection.. category _.code of'OxFF is reserved to specify a null entry for the category code. A null 
category, together with a zero length for the selection_caiegory_name.jengtrt and empty 
seiection_catsgory_n3me_texs field permits information to be carried in the descriptors field which 
may be unrelated to category codes (for example, the dccjocaiion_code_descriptor). 

se!ectfon_caiegory_(iaf-ie_!ength — An 8-bit unsigned integer .number that specifies the total length 
in bytes of the se!ection_category_name_textO field to follow. 

seieciion_category_name_textO A data structure containing a multiple string structure which 

specifies the selection criteria name, e.g. "Sports". Text strings are formatted according to the 
rules outlined in Section 6.10. The string for the se!ection_caiegory_name_t8xt0 shall be limited to 24 
characters or less. Currently defined category names are listed In Table 6.24 below. The category 
names shall appear exactly as defined in Table 6.24. 

The list of category names and their respective codes are broken down into two groups. The first 
group consists of codes 0x20 through 0x26 and may be called the "'Basic'' group. The second 
group contains the codes 0x27 through Ox AD and is called the "Detail'" group. The Basic group 
is used to define the broadcast program at the highest level. Use of the DCCT for categorical 
selection shall specify one or more of these Basic group codes to define the general category of 
the broadcast program. Broadcast programs which may fit more than one basic category may 
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specify several of these category names. The name ''Other" is used when the broadcast program 
doesn't realty fit into the other Basic categories. These Basic categories shall be specified before 
any of the categories from the Detail group. 

The Detail group may be used to add snore specific information if appropriate. These categories 
are optional and shall follow the Basic categories. Broadcast programs that may fit more than one 
Detail category may specify several of these categories. Only categories which actually apply to 
the broadcast program content should be specified. If the broadcast program cannot be accurately 
described with any of these categories, then none of them should be sent. In that case one of the 
categories from the Basic group would be all thai would be required. 

crc_32 — This is a 32-bit fle!d that contains the CRC value that ensures a zero output from the 
registers in the decoder defined in Annex A of ISO/JEC 13818- 1 '"MPEG-2 Systems" after 
processing the entire DCC Selection Code Table section. 

hide„giifde — The hide„guide bit found within the VCT should be set to 1 to prevent hidden 
channels used within a DCC request from being displayed in EPG displays. 
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Table 6,24 Categorical Selection Code Assignments 










Mranins 


v i ! . !Mt 


Meaning 


0x00 


Hoi Available 


0x4F 


nobby 


J?*?.9... --. 


.. A .\! ~ — 


0x01-1 F 


Reserved 


. '-'*?.9 


Hockey 


..' 3x . 8 .l. , 


Auto Racing 


0x20 


Education 




Ho!?18 


0x62 


Aviation 


0x21 


Entertainment 


®!55L_ 


J^ 0F [° r H 


.5?.?.? 


Biography 





Movie 


.5?:?.? 


Information 


.? x84 


Boaning 


0x23 


News 




instruction 




Bowling 


0x^4 


Religious 


0x55 


: Jofernairarsai 


°xS6 


":°*.":£. ,.. 


0x25 


Span's 


0x56 


: feitarview 




Cartoon 


0<?6 


Other 


Qx57 


Language ^ 


.™ 8S ... 


Children 


0x27 


Action 




Legal 


0X69 


v. 'i' 


0x28 




3*59 




QX8A 


■'■-■in'.;. 


1 ^-9 


Animated 


0x5A 


local 


0x88 


Computers 


6x2A 


Anthology 


0x5B 


fv1ai! "> 


S:'5*9 ,. 


Country Music 




Automobile 


_2i 6C 


Medical 




.. v 1 .'. _ ..... 


0x2C 


Awards 


0x5O 


Meeting 


.°* 8E 


Extreme Sports 


0x2D 


Baseball 


QxSfc 


Military 


0x ? F 


..f.?.'.V/-X,,... , ■■„,,. ■ 


Qx2E 


BaskettasS 




MiRteenes 


~~~ 


Financial 


0x2 ^ 


.J^M'L.... , 


9* 6 ?. ; 


Music 





Gymnastics_ _ 


°? 30 ~. 


Business 





Mystery 


° X ?JL_ , 


t ■■; iu ! : i s 


.'• >:3 .1.,....„ 


Classical 


0x62 


Rational 


..2.1^ ... 


• i'.f>e •< s .ci ■(.: 


,.9.* 32 ...... 


College 


9??? . .. 


..^'.V 58 .... 


. 0x94 — 


Huriting/Pishing/Outdoors 


0x33 


Cortibat 


0x64 


...;f;$?Sf ... 


0x35 


independent 


0x34 


Comedy 


0x65 


Politics 


0x96 


J "'~ .... — 


0x35 


Commentary 


0x66 


Pr8mier 


0x97 .... 


X!; ; 


0x36 


Concert 


0x67 


ffeteoQfded 


0x§8 


i t •''<>:" : 


0x37 


Consumer 


0x68 


'■ / 


0x99 


Musif/Fiim/Books 


0x33 


Contemporary 


0x89 


Piofessiona: 




News-lnternatiorial 


0x39 


Cnme 


0x6A 


1 


0x8B 


News-Local 


0x3A 


Osnce 


0x88 


Racing 


0x9C 


:SMB*N:atiQftSI 


0x38 


Documentary 


0x6C 


:--iJu 


0x86 


',..w. f' t J 


0x3C 


Drat" a 


0/6D 






'■i ,".r\ 


0x3D 


Elemertary 


OxSE 


Repeat 


0x9P 


Original 


0x3F. 


Erotica 


0x6F 




OxAO 




0x3F 


Exercise 


0x70 


. ,7 . — .-'lic 


0xA1 


■ t-i : ■:■ .t-j 


0x40 


Fantasy 


0x71 


Science 


QxA2 


Pop 


0x41 


Farm 


0x72 




OxA3 


r'.O 


0x42 


Fashion 


0x?3 




0xA4 


V I i i 


0x43 


Fiction 


0x74 


^Shopping 


0xA5 


Seif improvement 


0x44 


Food 


0x75 


Soap Opera 


GxA6 


Sitcom 


0x45 


Football 


0x76 


Special 


0xA7 


Skating 


0x46 


Foreign: 


^0x77 


Suspense 


0xA8 


Skiing 


0x47 


Fund Raiser 


0x78 


Talk 


0xA8 


Soccer 


0X18 


GameMite 


f 6x 7 9 


Technical 


QxAA 


1" Track/Field 1 


: 


Garden 


0x7A 




OxAB 




.-<<!<> 


I Gcif 


0X?B 




OxAC 


Volleyball 


0x4B 


Government 


0x7C 


: Variety 


OxAD 


Wrestling 


0x'.C 


Health 


0x7D 


video 


OxAE-EF 


Reserved 


0X4O 


High School 


0x7E 




OxFO-FE 


Reserved for expansion of 
Basic categories (e.g. 0x20- 
0x26} 


0x4£ 


History | 0x7F j Western 


OxFF 


Null (not a category) 
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11} Section 6,9 (old 6.7 Core Descriptors) 

Change the first sentence from: 

Table 6.16 lists all of the core descriptors and their descriptor tags. 

To: 

Table 6.25a and 6.25b list all of the core descriptors and their descriptor tags. 
12) Section 6.9 (oid 6.7 Core Descriptors) 
Change Table 8.16 to: 



Table 6,25a List of Descriptors for PSIP Tables. 



Descriptor Name 


Descriptor 
•ag 


Terrestrial 


P:\1T 




VCT 


KIT 


dcci 




stuffing descriptor 


0x80 














AC-3 audio descriptor 


0x81 








M 






caption service descriptor 


0x86 


O 






M 






content advisory descriptor 


0x87 


O 






M 






program identifier descriptor 




0 












extended channel name descriptor 


OxAO 






M 








.■ i'.m !■ .. .is.-!. U 


OxAl 






S 








i':;,'.-- '•■!!■.•' ■. s » 


0xA2 






M 








component name descriptor 


0x.A3 


r m 












dec departing tequest descriptor 


OkM 










M 




dee arriving 'request descriptor 


Ox.-V) 










M 




dee location code descriptor 


GxAB 














user private 


0xC0-0xFb 















Table 6.25b List of Descriptors for PSIP Tables. 



Descriptor Name 


Descriptor' 






Cable 






rag 


PMT 


vscr 


"vcr 


LIT 


x>ccx 


" if- w i 


stuffing descriptor 


0x80 














AC-3 audio riescriotor 


0\Xl 


S 






O 






caption service descriptor 


0x86 


M 






0 






cottteni advisory descriptor 


0x87 


M 






0 






progr.im identifier descriptor 




M 






0 






extended channel name descriptor 


OxAti 






M 








service location descriptor 


OxAi 






M 








time-shifted service descriptor 


0xA2 






M 








component name, descriptor 


0xA3 


M 












doc departing request descriptor 


0xA8 










M 




dec arriving request descriptor 


0xA9 










M 




dec location code descriptor 


OxAB 












M 


user private 


OxCO-OxFE 
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13) Section 8.9.2 (old 6,7,2 Program Identifier Descriptor) 
Replace with: 

6.9.2 Program Identifier Descriptor 

The program jdentifier_descriptor, as defined in Ref, [5], may be used in the PMT and must be 
used in EITs in order to enable use of the dcc_seiectionjypes of 0x03 or 0x04 in the Directed 
Channel Change Table. 

14) New Section 8.9.11 

Add the following new subsection: 

6.9.11 DCC Departing Request Descriptor 

This descriptor provides instructions for the actions to be performed by a DCCRR upon 
detection of a manual channel change requested by the viewer using either the channel change 
controls on the DCCRR or a remote control device just prior to executing the channel change 
itself. This function shall be defeatable by the viewer within setup menu selections and shall 
default to "not enabled" if the viewer does not explicitly enable it. 

The bit stream syntax for the dcc_departing_request_descriptor() is shown in Table 6.36. 



Table 6.36 Bit Stream Syntax for the DCC Departing Request Descriptor 



Syntax 


Bits Formal 


dcc_departing_request_descriptor() { 




descriptorjag 


8 0xA8 


descriptorjength 


8 uimsbf 


dcc_departing__request_type 


8 uimsbf 


dcc_departirTg_request_texiJenglh 


8 uimsbf 


dcc_departing_reques tjextf) 





descriptorjag — - This 8-bit unsigned integer shall have the value GxA8, identifying this descriptor 
as dcc_departing_request_descriptor(). 

descriptorjersgth — This 8-bit unsigned integer specifies the length (in bytes) immediately 
following this field up to the end of this descriptor. 

dcc_.departing_reqiiest_.type — This 8-bit unsigned integer specifies the type of the DCC departing 
request and shall have the values listed in Table 6.37. 

dcc_.departirig_request_.text jength — An 8-bit unsigned integer number that specifies the total 
length in bytes of the dcc_departing_request_text() field to follow. 

dcc_departing_request_text(} — The departing request window text in the format of a multiple 
string structure (see Section 6.10). 
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Table 6,37 DCC Beparimg Request Type Assignments 


Value 




0x00 


G'ETiiE'f'*: Ci'HOriiilCi r;;.j.iO< ■ OOMf'S-nc u N ; usef'li U:>! G-y. ..it-iSOMifij \i 1;^. 


0x01 


Cancel any outstanding departing request type and immediately perform a channel change upon 
request by the viewer. 


* 0x02 


Dispiay departing request text in a centered window for a minimum of 10 seconds prior to 
performing the channel change requested by the viewer or for a lesser amount of time if the 
viewer issues another channel change request or a "continue", "OK", "proceed", or equivalent 


* 0x03 


("Display departing request text m a centered window mdefi tely until viewer issues another 
channel change request or a "continue' 'OK' "proceed", or equivalent command 


QxO4~0xFF 





* Note: implementation of Departing Request types 0x02 and 0x03 are within the discretion of DCCRR 
manufacturers or may be disabled by viewers through an interactive setup session. 



15) New Section 6.9.12 

Add the following new subsection: 

6.9.12 DCC Arriving Request Descriptor 

This descriptor provides instructions for the actions to be performed by a DCCRR upon 
arrival at a newly changed channel. The arrival channel change request shall be executed within 
30 seconds of arrival at, and detection within, the channel PSIP stream (this implies that, and is 
dependent upon, the descriptor being repeated or issued by the broadcaster and detected by the 
DCCRR in at least 30 second cycles). The channel change shall be requested by the viewer using 
either the channel change controls on the DCCRR, or a remote control device. This function shall 
be defeatable by the viewer within setup menu selections and shall default to "not enabled" if the 
viewer does not explicitly enable it. 

The bit stream syntax for the dcc_arriving_request_descriptor() is shown in Table 6.38. 



Table 6.38 Bit Stream Syntax for the DCC Arriving Request Descriptor 



Syntax 


Bits Formal 


dcc_arriving_request_descriptor() { 




eiescriptor_Eag 


8 0xA9 


descriploMengtft 


8 uimsbf 


dec. arriving, request. type 


8 uimsbf 


dcc_arriving_request_textjength 


8 uimsbf 


dec arriving request text() 

} 





descriptor„tag — This 8-bit unsigned integer shall have the value 0xA9, identifying this descriptor 
as dcc_arriving_request_descnptor(). 

descriptorjength — This 8-bit unsigned integer specifies the length (in bytes) immediately 
following this field up to the end of this descriptor. 
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dcc_arrivirsgj"equest_type — This 8-bit unsigned integer specifies the type of the DCC arriving 
request and shal! have the values listed in Tabie 6.39. 

dee_arriying„request_texi jength — An 8-bit unsigned integer number that specifies the total 
length in bytes of the dcc_arriving_requesljext{) Held to follow. 

dcc_arriving_request_textQ — The arriving request window text in the format of a multiple string 
structure (see Section 6.10). 



Table 6.39 DCC Arriving Request Type Assignments 



Value 


Meaning 


0x00 


: v - )■ ■ -•>■ ■ " ■■' 1 ".v 'i ' - i . . 1 


0x01* 


Display arriving request text in a centered window for a minimum of 10 seconds after performing 
She channel cnange requested by the viewer, or for a less amount of time if the viewer issues a 
"continue", "OK 11 , "proceed'', or equivalent command. 


6x02* 


Display anting request text in a centered window indefinite!/ after performing a channel change 
request requested by the viewer until viewer issues a "continue", "OK", "proceed", or equivalent 
command. 


0x03-0xFF 


Reserved 



* Note: implementation of Arriving Request types OxO'i and 0\02 are within the discretion of DCCRR 
manufacturers or may be disabled by viewers through an interactive setup session. 



16) New Section 6.9.13 

Add the following new subsection: 

6.9.13 DCC Location Code Descriptor 

This descriptor provides information to be loaded into storage within the DCCRR to 
allow the viewer, through an interactive setup session, to select the state, county, and county 
subdivision of the viewer's location so that location codes, sent within a DCC request, may be 
identified and matched. The DCC Location Code Descriptor may appear within the descriptor 
loop of the DCC Selection Code Table (DCCSCT). The descriptor permits a DCCRR to acquire 
location names and code information from the DTV stream so that information -may be utilized in 
an interactive manner by a viewer to identify the state and county location lo the DCCRR. 

Each DTV station may emit a DCC Location Code Descriptor within the DCCSCT which 
contains only the information that particular DTV station considers to be within it's viewing 
coverage area. The DCCRR need only acquire a single copy of the location codes for a particular 
viewer - and It may be acquired from any DTV station within reception range of the DCCRR. 
Once the viewer has defined the codes to the DCCRR, the DCCRR need not acquire the DCC 
Location Code Descriptor again unless the viewer resets or moves the DCCRR. This mechanism 
of acquisition minimizes the number of repetitions that must occur within the broadcast stream 
and the frequency with which the DCCRR must parse the descriptor. 

The bit stream syntax for the dccjocation_code_descriptor() is shown in Tabie 6.40. 
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Table 6.40 Bit Stream Syntax for the DCC Location Code Descriptor 



Synlax 


Bits 


Format 


dcc_locatior\_code;_desc;:p!or() { 






descriptor tag 


8 


OxAB 


descriptorjefsgih 


8 


uimsbf 


dcc_statejocat!0»_code 


8 


uimsbf range 1.99 


decjsiate. iocat!on_code ioxs. ..length 


8 


uimsbf 


dcc_siate._!ocati'ori_code_text{;. 


var 




reserved 




'111111' 


dcc_.coiiFityJocauors__.CGde 


10 


uimsbf range 1.-999 


dcc_coijrstyJ<icatiori_c.ode_text_ieri9th 


8 


uimsbf 


dec county location code text!) 

} 







deseripiorjag — This 8-bii unsigned integer shall have the value OxAB, identifying this 
descriptor as dcc_location_code_descnptor(). 

descriptorjength — This 8-bit unsigned integer specifies the length (in bytes) immediately 
following this field up to the end of this descriptor, 

dcc_stateJocation_code — This 8-bit unsigned integer in the range 1 to 99 specifies the State or 
Territory, The dcc_state_iocation_code is coded according to State and Territory FIPS number codes 
(see 47 CFR 1 1.15(f),), 

dec_stateJocation_code_textJength — An 8-bit unsigned integer number that specifies the total 
length in bytes of the dcc_statejocation_code_text() field to follow, 

dcc_statejocation_code„text() — The name of a state in the format of a multiple string structure 
(see Section 6.10). 

dcc_county_iocatioo_code — This 10-bit unsigned integer in the range ! to 999 specifies a county 
within a state. The dcc_county_iQcatiori_code is coded according to State and Territory Federal 
Information Processing Standard (FIPS) number codes maintained by the National Institute of 
Standards and Technology (NIST) in FIPS PUB 6-4. 

dcc_county_Socat!Qn_code_textjengifc — An 8-bit unsigned integer number that specifies the total 
length in bytes of the dcc_countyjocation_code_text() field to follow. 

dcc_coiirstyJocatiori_code_text() — The name of a county in the format of a multiple string 
structure (see Section 6.10). 

17) New Section 7.3 

Add the following new subsection: 

7.3 Buffer Model Considerations to Support Directed Channel Change for 
Terrestriai Broadcast 

The maximum cycle time for the Directed Channel Change Table (DCCT) shall not 
exceed 150 ms, while a DCC request is in progress. The maximum cycle time for the DCCT 
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shall not exceed 400 ms, within iO seconds of an impending DCC request and 5 seconds 
following a DCC request. There shall be no maximum cycle time for the DCCT if there are no 
impending DCC requests. 

The maximum cycle time for the Directed Channel Change Selection Code Table 
(DCCSCT) shall not exceed 3.600,000 ms. ( I hour). 

18) New Section E7. DIRECTED CHANNEL CHANGE TABLE (DCCT) 

Renumber the existing section E7 (and tables) to E9 and add the following new 
subsection: 

E7. DIRECTED CHANNEL CHANGE TABLE 

The typical size for the DCCT is 44 bytes, with the assumption of having a single from/to 
channel, a single selection criterion, and no additional descriptors. The typical size for the DCCT 
(in bytes) based on the assumptions listed in the column "Assumption" is shown in Table E.7. 



Table E.7 Typical Size (bytes) of DCCT 



I Pisrf 


Size (byles) 


Assuroptio£s 


PSS header and trailer 


13 




message body 


3+(17*V)+(11*S) 


1 . No descriptors. 

2. V ■= number of virtual channels affected. 

3. 3 = numoer of selection criteria. 


| Total 


16+(17*V)+(11*S) 





19) New Section E8. DIRECTED CHANNEL CHANGE SELECTION CODE TABLE 
(DCCSCT) 

Renumber the existing section E8 (and tables) to E10 and add the following new 
subsection: 

E8. DIRECTED CHANNEL CHANGE SELECTION CODE TABLE 

The typical size for the DCCSCT is 26 bytes, with the assumption of having a single 
selection category and no additional descriptors. The typical size for the DCCSCT (in bytes) 
based on the assumptions listed in the column "Assumption" is shown in Table E.8. 
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Table E.8 Typical Size (bytes) of DCCSCT 



Pari 


Size (bytes) 


Assumption 


PS! header artd trailer 


13 




message body 


3+(Sc*(4+6)} 


1 . No descriptors. 

2. Sc = number of selection categories 

3. Seiection Category Name is compressed by Huffman coding 
with a standard table, and the text length after coding is 6 bytes. 


Total 


16+(Sc"10) | 
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20) New Annex H, An Overview of Directed Chanrsef Change 
Add the following new Annex: 

Annex H 

(Informative) 

An Overview of Directed Channel Change 

Directed Channel Change (DCC) is an optional capability that offers broadcasters, and 
other system operators the ability to steer viewers between linked, alternative streams of 
broadcast program content when viewers provide display systems with information that enables 
or controls the functionality. DCC permits broadcast program providers the ability to enhance 
their broadcast program content with offerings of alternative choices that can be selected directly 
by viewers or that can be automatically selected in display systems based upon information 
provided by viewers to indicate specific interests. It permits broadcasters and system operators to 
direct the attention of viewers to content which the broadcast program distributor has categorized 
and the viewer has elected to receive when available. Directed Channel Change provides 
broadcasters and system operators a great deal of flexibility in broadcast programming the DTV 
multiplex to provide content delivery services to targeted audiences, DCC is designed to be 
usefi.il on display systems that implement PSIP, without requiring additional, complex data 
processing capability. 

H1. INTRODUCTION 

A Directed Channel Change request is a trigger event sent within the PSIP stream of the 
DTV multiplex that will cause a "DCC-capable DTV reference receiver" (DCCRR) to select a 
different virtual channel from that to which it is already tuned. Depending upon the kind of DCC 
request, the change to a different virtual channel can occur without intervention by the viewer, if 
the viewer has enabled the capability by providing required information during a setup process or 
during operation of the display. Alternatively, the change can take place under direct control of 
the viewer, for instance using a remote control device. 

To enable the automatic carrying out of a DCC request within a DCCRR, the DTV 
viewer will be required to provide information to the display system. This may be accomplished 
through an interactive setup session or may be done during operation of the receiver, as different 
viewing options become available. The information provided by the viewer to the DCCRR will 
permit the unit to determine which, if any, alternate virtual channel the DCCRR should display 
upon receipt of a DCC request. This selection will take place through the DCCRR matching the 
viewer information with categorization information or other selection criteria sent by the 
broadcaster or system operator. There are also forms of DCC request that enable real time 
viewer selections among alternate broadcast program streams, such as, for example, alternate 
camera views of a sporting event. 
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H2. DCC SWITCH CRITERIA 

A switch from a currently viewed virtual channel to another virtual channel may be 
accomplished upon occurrence of any of the following selection criteria, some of which may be 
used in combination; 

5 Unconditional switch * 

• Postal code, zip code *, or location code 

• Program Identifier* 

• Demographic category 

* Content subject category 
s Authorization level 

* Content advisory value 

8 One of eight user categories* 

* Items required within a DTV device providing minimal support for Directed Channel Change within the 
United States. 

In addition to the criteria listed above that serve to include groups of viewers into a DCC 
request, several of the criteria may also be used to exclude viewers from inclusion in a request. 
For example, instead of listing many zip codes for inclusion of viewers in a DCC request, the 
inverse logic may be used to specify the group of all viewers not included within a group of zip 
codes, 

Two other DCC request actions have also been defined: an action to be taken upon a 
viewer switching away from a channel, and an action to be taken upon a viewer switching into a 
channel. 

The broadcaster may specify more than one type of selection criteria within a single DCC 
request. For example, it is possible to specify several individual zip codes by employing the loop 
structure within the DCC Table. 

H2.1 Unconditional Switch 

An unconditional switch would cause all viewers' channel, regardless of any other DCC 
selection criteria selected within the DCCRR, to switch to a specified virtual channel. A potential 
use of this criteria would be to aggregate viewers on different virtual channels to a single 
channel, 

H2.2 Postal Code, Zip Code, or Location Code 

A channel change based upon the viewer's location may be accomplished by using one or 
more of these criteria. Broadcasters may use these capabilities to provide targeted broadcast 
programming based upon a viewer's location within the viewing area. 

H2.3 Program Identifier 

A channel change based upon a broadcast program's episode and version number may be 
accomplished with this criteria. Use of this function would permit a broadcaster to direct a 
viewer's attention to a broadcast of a particular broadcast program having a certain episode and 
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version number. If the viewer had previously enabled a function within the DCCRR that would 
"remember" a particular broadcast program's episode/version number, the viewer could be 
directed to that broadcast program again upon detection of this criteria within the multiplex. 

H2.4 Demographic Category 

A Directed Channel Change may be accomplished using demographic categories as a 
switching criteria. Demographics such as age group and gender can be selected. 

H2.S Content Subject Category 

A channel change based upon the subject matter of the content of the broadcast program 
can be accomplished. Nearly 140 categories of subject matter have been tabulated that can be 
assigned to describe the content of a broadcast program. A broadcaster may use this category of 
DCC request switching to direct a viewer to a broadcast program based upon the viewer's desire 
to receive content of that subject matter. Although nearly 140 subject categories have been 
identified for inclusion in this revision of the specification, additional categories may be 
determined in the future and may be transmitted to the DCCRR through a table revision 
mechanism (the Directed Channel Change Selection Code Table). 

H2.6 Authorization Level 

A channel change may be accomplished using this mechanism in the event that the viewer 
attempts to switch to a virtual channel that he is not authorized to view. This category of DCC 
would permit the DCCRR to be directed to an alternative channel (such as a "barker" channel 
informing the viewer of his ineligibility to view the channel) instead of the channel the viewer 
attempted to tune. 

H2. 7 Content Advisory Level 

This category of DCC is similar to thai described in the preceding section (Authorization 
Level) but would redirect the viewer to another channel if the content advisory level in the 
DCCRR has been previously set above or below the value specified within this DCC request. 

H2.8 User Specified Category 

This category of DCC would allow a broadcaster to specify one of eight classifications of 
a broadcast program so that if a viewer pressed one of eight "'viewer-direct-select" buttons on a 
remote control, he would be directed to a virtual channel airing a broadcast program having that 
classification. This function would permit a broadcaster to define classifications not anticipated 
by this standard and then permit the viewer to be directed to broadcast programs or segments 
having those classifications. 

H2.9 Arriving/Departing Request 

Two additional Directed Channel Change request actions are specified. A Departing 
Request descriptor may be used within a DCC signal the occurrance of a departing request or to 
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cause a text box to appear for a definable amount of time prior to performing a channel change 
requested by the viewer, The text box may be used by the broadcaster to present information to 
the viewer, such as plot elements remaining in the broadcast program or upcoming segment 
schedule information. 

An Arriving Request descriptor may be used to signal the occurrences of an arriving 
request or cause a text box to appear for a definable amount of time upon arrival at a newly tuned 
virtual channel. For example, the text box may be used by the broadcaster to convey story line 
information up to this point in time, or even broadcast program schedule change or preemption 
information such as a broadcast program delayed announcement due to the previous or current 
broadcast program running long. 

H3. DOWNLOADABLE SELECTION CODE TABLE 

Through an optional downloadable table mechanism called the Directed Channel Change 
Selection Code Table, up to 255 content descriptions and selection codes may be delivered to 
DCC capable DTV reference receivers over the broadcast link. The table may be updated in the 
future to provide additional, or alternate, selection categories. An initial set has been provided 
within this standard to permit a baseline capability which may be extended, if required, by- 
industry agreement and revision to the standard. 

Through a downloadable table mechanism within the Directed Channel Change Selection 
Code Table, data necessary for a viewer to identify the location of the DCCRR may also be 
acquired without placing stringent memory requirements upon DCCRR designs to accommodate 
potentially voluminous data useful only during setup. 

The table is transmitted within the multiplex on a fairly infrequent basis - for example, no 
more frequently than once per hour. New category table editions may be identified by a table 
identification having a higher number than that currently loaded within the DCCRR. 
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t. SEC. 3.2: ACRONYMS AND ABBREVIATIONS 
Add the following abbreviation: 

DET Data Event Table 

2. SEC. 6.7: CORE DESCRIPTORS 

Revise the following table to mc.^Jc o ly the .10 •> aiaved out *ext fcr -he Re*'ft,t-.oi.r.o - Control 
(RC) descriptor OxAA and the footnote beiow: 

Table 6.2f a Lis* f t O^c p-o In J Si 5 Tables* 
Descriptor Name Descriptor Terresirsas 

Ta ^ FMT a/iGl VCT E:T DCC" DCCSCT 




redistribution control descriptor 
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Table 6.26b List of Descriptors for PSIP Tables 



Descriptor Name Descriptor Cable 

Tas PMT I MGT i VCT i EiT i DCCT ! DCCSCT 



rcdfStr-'Jj'IOr. cO'tfro! Ci'JSC nptor 



3, SEC, 6.7.11: ADD SECTION FOR REDISTRIBUTION CONTROL DESCRIPTOR 
Add the following section: 

6.7.11 Redistribution Control (RC) Descriptor 

The purpose of the Redistribution Control descriptor is to convey a certain type of redistribution 
information held by the program rightsholder for audio, video, or data events. The descriptor's 
existence within the ATSC stream shall mean: "techrsoiogicai control of consumer redistribution 
is signaled." 

The redistribution control information conveyed by the rc_descriptor() defined in Tabic 6.24 
concerns the video/audio/data programming identified either by the event _id within the EIT or the 

program_number within the PMT. 

For terrestrial broadcast transport, the rc_descriptor(), when transmitted, shall be present in both 
the EIT and PMT. For cable transport, the rc_descripk>r{), when transmitted, shall be present in the 
PMT, and, when the EIT is carried, in the EIT. 

The rc_descriptor(), when in the EIT, shall apply to a specific event associated with the Virtual 
Channel and the related MPEG-2 Program. It shall be placed within the descriptor loop after 
descriptorsjength for the event_id for which this information is being signaled. The rc.„descriptor(), 
shall be placed within the descriptor loop after programjnfojength in the TSjjrogram_map_sec«on for 
the program_number for which this information is being signaled. When the descriptor is placed in 
the PMT, it shall also be placed in the current event of EIT-0 for the Virtual Channel associated 
with the MPEG-2 Program; and it should be placed in the EIT for this event as far in advance as 
possible (i.e. minimally EIT- 1, EIT-2, and EIT-3). 



' When the EIT is present. 
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For data-only services 2 , the rc_descriptor() shall be placed in the DET (whose syntax and 
semantics are defined in ATSC A/90 Data Broadcasting Standard) under the same provisions 
described for the EIT. 

It is out of the scope of this standard to assert how any receiving device reacts when the 
rc_descriptor is present, 

The bit stream syntax for the redistribution control descriptor is shown in Table 6.24. 

Table 6.24 Bit Stream Syntax for the Redistribution Control Descriptor 



Syntax 


No. of Bits Format 


rc_descriptor() { 




descriptor, tag 


8 lOxAA 


descriptorjength 


8 uimsbf 


for (i = 0; i < descriptorjength; }++) { 




rc intormatiorsO 


8 | utmsbf 


5 i 


} | | 



descrfptorjag — This 8-bit unsigned integer shall have the value QxAA, identifying this 
descriptor as the rc_descriptor(). 

descriptorjength — This 8-bit unsigned integer specifies the length (in bytes) immediately 
following this field through the last byte of this descriptor. The descriptorjength may, in the 
future, have a value other than 0x00. If the descriptorjength is not 0x00, optional information 
having a length of descriptorjength shall be contained within the rcjnformation field. 

Fc_information() — Optional additional redistribution control information that may be defined in 
the future. 



J As defined In the ATSC A/90 Data Broadcast Standard. 
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